1) Diagnostic Identity

Diagnostic Name: Dependency Load

Short Name / Symbol: dependency_load

Diagnostic Class: Coupling / Reliance Burden / Interface Risk / Compatibility / Systemic Exposure

Primary Function: Estimate the reliance burden created when one node, system, process, agent, institution, tool, relationship, resource, metric, memory, or boundary condition depends on another for function, repair, coherence, access, identity, continuity, or survival.

Primary Use: Determine whether a coupling creates sustainable interdependence, fragile dependency, hidden obligation, repair burden, exit-cost escalation, or coherence loss.

Core Risk if Ignored: The system may treat coupling as compatibility while dependency quietly shifts burden, reduces autonomy, raises exit cost, overloads repair capacity, or creates systemic fragility.

Core Risk if Overtrusted: Any dependency may be treated as incoherent, causing the system to reject healthy interdependence, specialization, trust, support, mutuality, or necessary coupling.

2) Mechanical Definition

dependency_load measures the amount of reliance burden created by a coupling relative to the system’s compatibility, boundary integrity, restoration capacity, exit capacity, and ability to remain coherent if the dependency changes or fails.

dependency_load answers:

How much does this system now rely on that system, and what burden does that reliance create?

Dependency is not inherently bad.

Healthy dependency can appear as:

mutual support
specialization
trusted interface
shared infrastructure
division of labor
stable repair pathway
coherent cooperation

Dependency becomes load when reliance creates:

fragility
obligation pressure
asymmetric repair burden
loss of refusal
exit-cost escalation
hidden debt
delayed adaptation
single-point failure
coercive coupling
resource capture
identity erosion

The key distinction:

interdependence supports coherence
dependency load consumes coherence

3) What the Diagnostic Measures

Direct Measurement Target

dependency_load measures:

• reliance burden
• coupling burden
• repair dependence
• resource dependence
• informational dependence
• logistical dependence
• emotional / relational dependence where relevant
• identity dependence
• memory dependence
• permission dependence
• access dependence
• infrastructure dependence
• authority dependence
• metric dependence
• exit difficulty created by reliance
• autonomy reduction
• fragility from single-point reliance
• burden transfer across coupling

Indirect / Proxy Signals

dependency_load can be estimated from:

• inability to function without the dependency
• rising exit cost
• rising switching cost
• repeated waiting on another node
• repair requiring another node’s cooperation
• one node carrying another’s logistics
• one node absorbing another’s instability
• loss of local fallback paths
• dependency becoming invisible infrastructure
• increased boundary strain
• increased obligation after support
• decreased refusal capacity
• one node’s failure cascading into another
• dependency expanding beyond original scope
• support becoming control
• access being conditioned on compliance
• compatibility declining as reliance grows
• dependency remaining after original need passes

What It Does Not Measure

dependency_load does not directly measure:

• whether dependency is bad
• whether trust is incoherent
• whether coupling should end
• whether autonomy means isolation
• whether support is coercive
• whether specialization is unsafe
• whether all redundancy is necessary
• whether independence is always preferable
• whether the dependency holder is at fault
• whether dependency was created intentionally
• whether exit should happen immediately

High dependency_load means reliance burden is significant.

It does not automatically mean the coupling is incoherent if the dependency is mutual, auditable, repairable, and freely maintainable.

Low dependency_load means reliance burden is low.

It does not automatically mean the system is stronger if low dependency also means isolation, lack of support, or missing infrastructure.

4) Canonical State Variables Involved

Canonical state vector:

S = {O, H, ε, ι, Au, µᵢ, BΣ, K, R, Φ}

Primary Variables

• K: compatibility determines whether dependency increases mutual coherence or creates burden
• BΣ: boundary integrity may weaken if dependency reduces refusal, exit, or identity clarity
• R: restoration capacity may be consumed or externalized through dependency
• H: hidden debt rises when reliance costs are unacknowledged or unrepaired
• O: coherence depends on whether dependency supports or drains system function
• Au: dependencies must be traceable enough to identify burden, fragility, and repair pathways

Secondary Variables

• ε: visible error may appear when dependency fails or overloads
• ι: pseudo-coherence may appear when dependency stabilizes surface function by exporting cost
• µᵢ: integrity can degrade when a node’s action, identity, or continuity depends on another beyond consent or fit
• Φ: performance metrics may improve while dependency load accumulates beneath them

Variables Commonly Confused With dependency_load

5) Localization Signature

Primary Legibility Layers

• U1 — Power / Budgets: resources, money, energy, labor, compute, time, staffing, material support
• U2 — Configuration / Boundaries: permissions, access, refusal, exit, contracts, gates, and boundary dependence
• U3 — Execution: runtime dependence, operational reliance, workflow dependence
• U5 — Coordination / Time: scheduling, sequencing, waiting, response dependence, escalation dependence
• U6 — Coherence Field: whole-system effects of reliance, fragility, and mutual fit
• U7 — Memory / Recurrence: dependency history, learned reliance, habitual outsourcing, inherited dependence

Primary Leverage Layers

• U1: rebalance resources or create redundancy
• U2: clarify boundaries, contracts, refusal, exit, and access conditions
• U3: create fallback execution paths
• U5: reduce waiting, bottlenecks, or timing dependency
• U6: evaluate compatibility under reliance
• U7: update dependency memory and prevent recurrence of hidden reliance debt

Verification Layers

• U1: is resource reliance sustainable?
• U2: is refusal or exit still possible?
• U3: can execution continue if dependency fails?
• U5: does dependency introduce unsafe delay?
• U6: does coherence increase or decrease?
• U7: does dependency become habit, precedent, or inherited structure?

Common Mislocalizations

• Treating support as compatibility
• Treating dependency as trust
• Treating reliance as loyalty
• Treating exit difficulty as commitment
• Treating resource provision as repair
• Treating specialization as immunity from fallback planning
• Treating fragility as efficiency
• Treating one node’s burden as mutual benefit
• Treating hidden dependency as stability
• Treating inability to refuse as agreement
• Treating dependency failure as isolated event
• Treating reduced autonomy as coherence

6) Input Requirements

Required Inputs

To estimate dependency_load, the system needs:

• dependency being evaluated
• dependent node/system
• relied-upon node/system
• dependency type
• dependency depth
• dependency duration
• affected variables in S
• resource flow
• repair flow
• permission / access conditions
• refusal conditions
• exit or switching conditions
• fallback paths
• dependency failure impact
• affected-node feedback
• boundary strain
• repair burden distribution
• recurrence history

Optional Inputs

These improve precision:

• dependency map
• contract / agreement history
• resource asymmetry map
• exit-cost estimate
• switching-cost estimate
• single-point-failure analysis
• uptime / reliability data
• dependency failure incidents
• fallback test results
• coupling propagation records
• repair burden records
• timeline of dependency growth
• dependency scope creep
• hidden obligation reports
• access-control data
• rank / role asymmetry
• stress-test results
• affected-node cost
• compatibility tests

Missing Input Behavior

If dependency_load inputs are missing:

• If fallback paths are unknown, assume fragility may be higher
• If exit cost is unknown, dependency may be more coercive than it appears
• If repair burden is unknown, load may be externalized
• If resource flow is unknown, dependency may be hidden
• If boundary strain is unknown, BΣ risk is under-sampled
• If affected-node feedback is missing, burden may be invisible
• If dependency duration is unknown, temporary support may have become structural
• If failure impact is unknown, stress test before scaling dependence

Default missing-input posture:

map reliance → map fallback/exit → check burden distribution → test dependency failure → recalibrate coupling

7) Diagnostic States / Ranges

These ranges are qualitative and should be domain-calibrated.

Healthy / Coherence-Supporting Range

Dependency is mutual, bounded, auditable, repairable, and compatible with boundary integrity.

Signals:

• reliance is explicit
• burden is acknowledged
• fallback paths exist or are intentionally unnecessary
• refusal remains possible
• exit is coherent
• support does not become control
• repair burden is not one-sided
• dependency improves K_real
• BΣ remains intact
• dependency failure is survivable or planned for
• memory preserves scope and conditions

Recommended posture:

maintain coupling
monitor dependency growth
preserve fallback/exit paths
review K_real and repair burden over time

Watch Range

Dependency is growing or becoming more consequential, but may still be coherent.

Signals:

• fallback paths weaken
• exit cost rises
• one node waits more often
• scope of reliance expands
• support creates unclear obligation
• boundary strain increases
• repair burden begins shifting
• dependency is no longer temporary
• failure impact increases
• affected nodes raise concerns about reliance

Recommended posture:

map dependency expansion
clarify terms
review exit/fallback
check repair burden
retest compatibility under stress

Degraded Range

Dependency creates hidden burden, fragility, or asymmetric reliance.

Signals:

• one node cannot function without the other
• refusal becomes costly
• exit becomes difficult
• repair burden is one-sided
• dependency spreads into new domains
• boundary strain rises
• failure cascades through coupling
• support becomes control or obligation
• autonomy degrades
• dependency is denied or minimized
• H accumulates beneath stable function

Recommended posture:

⊘ attenuate coupling
restore fallback paths
reduce dependency scope
redistribute repair burden
repair BΣ and exit capacity

Contraindicated:

deeper coupling
irreversible composition
expanding reliance
declaring compatibility from dependence
forcing continued coupling
removing fallback paths

Critical / Collapse-Prone Range

Dependency becomes coercive, fragile, identity-eroding, or systemically dangerous.

Signals:

• exit is practically impossible
• one node controls essential access
• one failure cascades widely
• repair cannot occur without the dependent structure
• dependency holder cannot refuse or renegotiate
• coercive fusion risk is high
• identity or boundary integrity degrades
• dependency is used to enforce compliance
• affected nodes carry chronic unrepaired burden
• system survival depends on an unaccountable node or structure

Recommended posture:

stop dependency expansion
restore minimal autonomy
create emergency fallback
repair exit/refusal pathways
redistribute resources
attenuate coercive coupling
validate BΣ recovery

False Positive Risk

dependency_load may appear high when:

• interdependence is healthy and mutual
• specialization is intentional and well-governed
• fallback is unnecessary because trust and repair are strong
• dependency is temporary and scoped
• support is freely chosen and reversible
• redundancy would create more burden than resilience
• reliance increases O without degrading BΣ
• coupled nodes have strong repair and exit agreements

False Negative Risk

dependency_load may appear low when:

• dependency is normalized
• support infrastructure is invisible
• one node quietly carries repair burden
• exit has never been tested
• dependency is emotional, informational, or reputational rather than material
• access control is subtle
• switching cost is hidden
• dependency only appears under stress
• low-power nodes cannot express burden
• public autonomy hides practical reliance

8) Leading Indicators

dependency_load degradation appears early as:

• fallback paths quietly disappear
• “temporary” reliance becomes routine
• one node starts waiting more often
• support creates expectation
• refusal becomes harder
• dependency language increases
• switching feels unrealistic
• boundary strain rises after support
• one node absorbs more repair work
• dependency expands beyond original scope
• access becomes conditional
• stress reveals fragility
• alternatives stop being maintained
• maintenance of autonomy is treated as inefficient
• dependency is defended as loyalty or efficiency

9) Lagging Indicators

dependency_load failure has already accumulated debt when:

• exit becomes impossible
• cascading failure occurs
• one node cannot function independently
• repair burden is chronically one-sided
• dependency becomes coercive
• identity or boundary integrity is degraded
• trust collapses after dependency failure
• affected nodes exit or rupture
• external intervention is required
• dependency provider becomes unaccountable
• old fallback paths are gone
• hidden dependency becomes public shock
• system must restructure around dependency failure

10) Interpretation Rules

How to Read dependency_load

dependency_load should be read as:

context-specific reliance burden created by coupling

It is not anti-dependency.

A system may have:

• high dependency and high coherence if reliance is mutual, repairable, and freely maintained
• high dependency and low coherence if refusal/exit/repair are weak
• low dependency and low coherence if isolation blocks needed support
• low dependency and high coherence if autonomy and exchange are balanced
• high material dependency but low identity dependency
• low material dependency but high informational or emotional dependency
• hidden dependency that appears only under stress

What Changes Its Meaning

dependency_load changes meaning under:

• high exit_cost
• high repair_burden_asymmetry
• low R_eff
• low Au_eff
• low EB
• weak FI_integrity
• high boundary_strain
• miscalibrated Perm(t)
• high resource_asymmetry
• high stress_divergence
• high coupling_propagation_risk
• high Φ pressure
• strong rank asymmetry
• low M_int(t)
• high U8 forcing

Context Modifiers

High exit_cost: dependency becomes harder to call voluntary.

Repair burden asymmetry: reliance may become extractive.

Low R_eff: dependency failures may not be repairable.

Low Au_eff: burden and reliance may be hidden.

Low EB: affected nodes may not express dependency strain.

High boundary_strain: reliance may be damaging BΣ.

Miscalibrated Perm(t): dependency may force inappropriate access or closure.

High resource_asymmetry: dependency may become control.

High stress divergence: dependency may fail under pressure.

Domain Calibration Notes

dependency_load should be calibrated by domain:

• in engineering: service dependencies, libraries, vendors, infrastructure, release pipelines, data sources
• in AI: tool dependencies, memory dependencies, retrieval dependencies, policy dependencies, model-provider dependencies
• in institutions: funding dependence, staffing dependence, procedural dependence, vendor dependence, authority dependence
• in governance: supply chains, legal authority, fiscal dependency, jurisdictional dependency, public-service dependency
• in relationships: support dependence, time dependence, emotional availability, repair dependence, logistical reliance
• in archives: source dependency, glossary dependency, canon dependency, cross-link dependency, platform/tool dependency

11) Operator Sequencing Implications

If dependency_load Is Healthy / Bounded

Allowed with ordinary gate checks:

• ⊗ coupling can continue
• Λ compatibility can pass with monitoring
• Γ can select dependency as efficient support
• Π can define roles and boundaries
• ℛ can use dependency channels for repair
• U7 can store dependency scope and conditions
• Δ stress tests can validate fallback paths

Recommended:

Λ compatibility check → Π dependency scope → ⊗ coupling → Au dependency record → Δ fallback test → U7 update

If dependency_load Is High or Degraded

Recommended:

map reliance → restore fallback/exit → reduce dependency scope → redistribute repair burden → retest K_real

Or:

⊘ attenuate coupling → repair BΣ → rebuild autonomy where needed → renegotiate terms

Avoid or delay:

• deepening coupling
• irreversible ⊕
• removing fallback paths
• expanding dependency scope
• declaring compatibility from dependence
• forcing continued reliance
• scaling on fragile dependency
• using support as control

Operators Recommended Under High dependency_load

• Λ: re-evaluate real compatibility
• Π: define dependency boundaries, scope, refusal, and exit
• ⊘ Attenuation: reduce reliance load
• Au: trace dependency and burden
• ℛ: repair autonomy, fallback, and burden asymmetry
• Γ: select which dependencies to keep, reduce, replace, or diversify
• Θ: damp urgency to deepen dependency
• Ξ: detect pseudo-coherence funded by hidden reliance

Operators Contraindicated Under High dependency_load

• ⊗ deep coupling: increases reliance burden
• ⊕ composition: may erase boundary before dependency is repaired
• Τ acceleration: scales dependency fragility
• Π access hardening by dependent party: may trap dependency
• Γ closure selection: may declare dependency healthy without exit test
• Σ escalation: may sacralize dependence as loyalty
• ✕ force: turns dependency into coercive coupling

12) Gate Implications

Gates Strengthened By Reliable dependency_load Reading

• Au-Actuation: dependency pathways are traceable
• FI-Gate: dependent nodes can report burden and failure
• High Risk Gate: prevents high-risk binding under dependency-distorted conditions
• MS-Gate: checks repair burden and dependency burden symmetry
• ☷ᵢ: protects boundaries and principles from coercive reliance

Gates Weakened If dependency_load Is Poorly Known

If dependency load is unknown:

• Au may miss hidden reliance
• FI may not surface dependency strain
• High Risk Gate may bind identity/status from dependency-shaped signal
• MS may miss asymmetrical burden
• ☷ᵢ may validate dependence that violates boundary principles
• Π may remove needed exit paths
• Λ may falsely confirm compatibility
• ℛ may repair symptoms while dependency generator persists

Gate Outcomes Affected

High dependency_load should push gates toward:

• Pause deeper coupling
• Require dependency map
• Require fallback / exit review
• Require repair-burden review
• Require BΣ check
• Require stress test
• Deny irreversible composition
• Deny forced continuation
• ∅ for high-impact coupling where dependency load exceeds repair and exit capacity

13) Scaling Behavior

dependency_load becomes more dangerous under scale because dependencies multiply, concentrate, and become invisible infrastructure.

As systems scale:

• dependencies become layered
• single points of failure hide inside networks
• switching costs rise
• dependency providers gain leverage
• fallback paths decay
• repair requires multiple nodes
• one dependency failure cascades
• dependency maps become outdated
• dependency is normalized as infrastructure
• hidden labor supports visible autonomy
• resource asymmetry increases
• exit becomes politically, technically, or emotionally costly
• coupling depth outpaces compatibility validation
• dependency memory becomes incomplete

Scaling Risks

• cascading failure
• vendor / platform lock-in
• resource capture
• coercive dependency
• hidden infrastructure debt
• repair bottleneck
• exit-cost escalation
• boundary erosion
• single-point failure
• dependency blindness
• pseudo-coherence through support export
• support/control inversion
• autonomy loss
• repair burden asymmetry
• resilience theater

Scaling Requirements

To scale dependency safely, systems need:

• dependency maps
• fallback paths
• exit strategies
• redundancy where needed
• dependency scope records
• resource-flow tracking
• repair-burden tracking
• compatibility retesting
• stress testing
• dependency failure drills
• switching-cost estimates
• boundary impact review
• affected-node feedback
• dependency memory with provenance
• concentration risk analysis
• dependency sunset/review cadence

Scaling Rule

Dependency must scale only with compatibility, boundary integrity, repair capacity, and exit capacity.

Sanity constraint:

dependency_load > R_eff + exit_capacity ⇒ coercive fragility risk ↑

If reliance exceeds repair and exit capacity, the dependency becomes increasingly coercive or fragile.

Second constraint:

dependency_load × coupling_depth > 𝓑(t) ⇒ cascade risk ↑

If dependency load across coupling exceeds bandwidth, disturbance can propagate.

Third constraint:

dependency_load ↑ + BΣ↓ ⇒ coercive_fusion_risk ↑

If reliance grows while boundary integrity falls, fusion risk rises.

14) Interaction / Coupling Behavior

dependency_load is a core coupling diagnostic because all sustained coupling creates some reliance.

What It Reveals About Coupling

• whether coupling creates mutual support or asymmetric burden
• whether one node becomes necessary to another’s function
• whether fallback remains available
• whether repair requires dependency provider cooperation
• whether support is becoming control
• whether dependency deepens without compatibility
• whether one node’s failure propagates into another
• whether reliance is transparent or hidden

What It Reveals About Boundary Integrity

Dependency changes boundaries.

When dependency_load is high:

• refusal can become harder
• exit can become costly
• access can become leverage
• support can become obligation
• boundary strain can rise
• BΣ may erode through repeated reliance
• identity clarity may blur
• repair may require renegotiating the dependency

What It Reveals About Compatibility

Compatibility requires sustainable dependency.

A coupling may be unsafe if:

one node’s coherence requires another node’s depletion

or:

dependency grows faster than boundary repair and exit capacity

Healthy compatibility can include dependency, but only when dependency is mutual, transparent, repairable, and non-coercive.

Relevant Interface Acts

• ↺ Reflection: name the dependency and burden clearly
• ⊘ Attenuation: reduce reliance while strain is repaired
• ⇩ Relaxation: reduce pressure created by dependency
• ⊙ Alignment: clarify one’s own dependency needs and limits
• →? Invitation: offer support without creating hidden obligation
• ⚕︎ Restorative Override: requires post-action dependency repair
• ✕ Force: dangerous when used through dependency leverage

15) Failure Modes Detected

Primary Failure Modes

dependency_load detects or predicts:

• dependency fragility
• coercive reliance
• exit-cost escalation
• repair burden asymmetry
• support/control inversion
• boundary erosion
• single-point failure
• hidden reliance
• infrastructure lock-in
• vendor/platform capture
• coupling cascade
• autonomy loss
• dependency denial
• fallback decay
• obligation creep
• pseudo-coherence through exported support
• dependency-driven hidden debt

Composite Regimes Where dependency_load Matters

• Coercive Fusion: dependency erodes BΣ and refusal/exit
• Extraction Regime: one node relies on another while exporting repair burden
• Goodhart Collapse: dependency supports Φ while O falls
• Crisis Loop: dependency failure recurs without repair
• Pseudo-Coherent Basin: stability is maintained by hidden reliance
• Mission Lock: dependency is justified by trajectory
• LOS: latent dependency governs beneath formal autonomy
• Repair Theater: dependency burden is acknowledged but not reduced
• Compression Collapse: dependency narrows available choices

16) Accountability & Reintegration Implications

If dependency_load Was Ignored

Likely consequences:

• coupling became fragile
• exit became costly
• support became control
• repair burden shifted asymmetrically
• fallback paths disappeared
• affected nodes carried hidden reliance
• dependency failure cascaded
• autonomy was overstated
• compatibility was overclaimed
• hidden debt accumulated through reliance

Accountability questions:

• Who depended on whom?
• For what?
• How deeply?
• Was the dependency explicit?
• Was refusal possible?
• Was exit possible?
• Who carried repair burden?
• Did support create obligation?
• Did dependency improve K_real?
• Did dependency degrade BΣ?
• Were fallback paths preserved?
• Did dependency become coercive?

If dependency_load Was Misread

Possible misread forms:

• healthy support mistaken for coercion
• interdependence mistaken for weakness
• specialization mistaken for fragility
• trust mistaken for dangerous dependency
• exit capacity ignored because current relationship is good
• dependency denied because it is normalized
• support mistaken for compatibility
• reliance mistaken for loyalty
• dependency burden blamed on the dependent node alone
• autonomy claimed while hidden support persists

Required Restoration

When dependency_load failure is found:

map dependency
→ identify reliance depth and burden
→ review exit/refusal/fallback
→ redistribute repair burden
→ reduce unnecessary reliance
→ repair BΣ
→ retest compatibility under stress
→ update U7 dependency memory

If dependency burden was asymmetric, MS-Gate should review who relied, who supplied, who benefited, and who carried cost.

17) Cross-Domain Examples

Technical / Engineering

A platform depends on one external API for critical function. It performs well until the API changes, causing cascading failure.

Diagnostic implication: dependency load was high and fallback capacity was low.

Operator sequence: dependency map → fallback design → interface contract repair → stress test → U7 dependency record.

Institutional / Governance

A public service relies on a single vendor or department for core operations. When that node fails, the whole service stalls.

Diagnostic implication: operational dependency became hidden infrastructure fragility.

Operator sequence: vendor dependency audit → redundancy plan → contract boundary repair → service continuity test.

AI / Algorithmic

An AI system depends heavily on retrieval memory. When retrieval is stale or contaminated, the model appears to fail even though the origin is dependency quality.

Diagnostic implication: output coherence depends on memory/retrieval layer integrity.

Operator sequence: retrieval dependency audit → source freshness repair → memory provenance → Δ retrieval-failure tests.

Interaction / Relational

One person becomes the primary emotional, logistical, or repair stabilizer for the relationship. The relationship appears stable, but only because one node carries most recovery labor.

Diagnostic implication: dependency load is asymmetrical and may be funding pseudo-coherence.

Operator sequence: ↺ dependency reflection → repair-burden redistribution → boundary repair → Λ compatibility re-test.

Archive / Framework Design

The archive depends on a central glossary. If the glossary drifts or lags, all downstream modules inherit confusion.

Diagnostic implication: glossary dependency load is high and must be supported by strong U7 maintenance.

Operator sequence: dependency map → glossary hardening → cross-link checks → version-control repair → reader stress-test.

18) Test Protocols

1. Dependency Map Test

What depends on what?

Failure signal: reliance pathways are unknown.

2. Failure Impact Test

What happens if the dependency fails?

Failure signal: failure cascades beyond expected scope.

3. Fallback Test

Is there a fallback path?

Failure signal: no alternative exists or fallback is untested.

4. Exit Test

Can the dependency be reduced or ended coherently?

Failure signal: exit is practically impossible.

5. Refusal Test

Can either node refuse expanded dependency?

Failure signal: support has become obligation.

6. Repair Burden Test

Who repairs dependency failures?

Failure signal: one node carries most restoration.

7. Boundary Integrity Test

Does the dependency preserve BΣ?

Failure signal: reliance erodes identity, permission, or role clarity.

8. Compatibility Test

Does dependency increase K_real?

Failure signal: dependence rises while mutual coherence falls.

9. Stress Test

Does the dependency hold under load, scarcity, or disruption?

Failure signal: calm-state support fails under stress.

10. Scope Creep Test

Has dependency expanded beyond its original purpose?

Failure signal: dependency quietly spreads into new domains.

19) Anti-Patterns

• Support as compatibility
• Dependency as loyalty
• Exit cost as commitment
• Reliance as trust
• Specialization without fallback review
• Single point as efficiency
• Hidden support as autonomy
• Support becoming control
• Dependency denial
• Temporary reliance as permanent structure
• No fallback as confidence
• Repair burden on the supporting node
• Dependency failure as isolated event
• Resource access as consent
• Switching cost ignored
• Coupling without exit review
• Performance success as dependency health
• Dependency growth as relationship strength
• Autonomy claimed over hidden infrastructure
• Compatibility declared from need

20) Spec Validation Check

• Is this truly a diagnostic, not an operator? Yes.
• Does it measure state, capacity, risk, or response rather than act directly? Yes.
• Does it map to S? Yes.
• Are U-layers specified? Yes.
• Are leading and lagging indicators separated? Yes.
• Are interpretation risks defined? Yes.
• Are operator sequencing implications clear? Yes.
• Are gate implications clear? Yes.
• Are scaling risks included? Yes.
• Are interaction implications included? Yes.
• Does it avoid new primitives? Yes.

Condensed Archive Summary

dependency_load is the diagnostic estimate of the reliance burden created when one node, system, process, agent, institution, tool, relationship, resource, metric, memory, or boundary condition depends on another for function, repair, coherence, access, identity, continuity, or survival. It does not treat dependency as inherently incoherent; healthy interdependence can support coherence when explicit, mutual, bounded, repairable, and exit-capable. High dependency_load indicates risk of fragility, exit-cost escalation, repair burden asymmetry, support/control inversion, boundary erosion, hidden reliance, fallback decay, coupling cascade, coercive dependency, and pseudo-coherence funded by exported support. Under high dependency_load, the system should map reliance, preserve or restore fallback and exit paths, reduce dependency scope, redistribute repair burden, repair BΣ, retest K_real under stress, and avoid deepening coupling or irreversible composition until dependency burden is coherent.