Dependency

Prime #

None

Origin domain

Computer Science & Software Engineering

Also from

Organizational & Management Science, Philosophy, Biology & Ecology

Aliases

Reliance, Directed Reliance

Core Idea

Dependency is the directed relation in which the state, action, availability, meaning, or success of one element relies on another being present, prior, compatible, or supplied. It names the asymmetry where A cannot proceed, function, be interpreted, or retain its value unless B is met. Dependencies can be material, informational, temporal, logical, social, or institutional — but the core commitment is directed reliance: A depends on B, where removing or violating B impairs A in a specifiable failure mode. Dependencies compose into chains, graphs, cycles, bottlenecks, and layered architectures wherever multiple elements interact.

How would you explain it like I'm…

Needs Something Else

If you want to draw, you need a crayon. The drawing depends on the crayon — without it, you can't draw. That's a dependency: one thing needs another thing first. If you stack blocks, each block depends on the one underneath to hold it up.

Relies On

A dependency is when one thing needs another thing to work or exist. The relationship has a direction: A depends on B, but B might not depend on A. If B isn't there, or is broken, then A can't function. You see this everywhere: a recipe step needs the previous step done first, a sentence needs a noun before a pronoun can refer to it, and an animal needs a particular plant to live. When you chain dependencies — A needs B, B needs C — then A secretly needs C too.

Directed Reliance

Dependency is the directed relation in which one element relies on another being present, prior, compatible, or supplied. A depends on B means A cannot proceed, function, or hold its value unless some condition on B is met — and the relation has a direction (asymmetric reliance), not just correlation. The same shape shows up across domains: production needs upstream parts, calculations need input values, theorems need lemmas, sentences need referents, contracts need triggering conditions. What unifies them isn't the content but the shape: a directed reliance with a specifiable failure mode if the relied-on condition fails. Dependencies compose: a chain (A depends on B depends on C) makes A also depend on C, even when no direct link was named.

 

Dependency is the directed relation in which one element relies on another being present, prior, compatible, or supplied. A depends on B means A cannot proceed, function, be interpreted, or retain its value unless some condition on B holds. The relation is asymmetric — reliance flows one way — and is accompanied by a specifiable failure mode when the condition on B fails. The same structural shape recurs across domains: material (downstream production needs upstream parts), informational (a calculation needs an input), temporal (a later event needs an earlier one), logical (a theorem needs a lemma), semantic (a referring expression needs a referent), and institutional (a contractual obligation needs a triggering condition). What unifies them isn't content but shape. Dependencies compose: a chain A depends on B depends on C makes A transitively depend on C, even with no direct link named. A graph of dependencies produces architecture — layered, modular, hierarchical, or cyclic — with topological sort as the canonical linearization.

Broad Use

• Software engineering: import/library dependency graphs, build systems, transitive dependency resolution; "a depends on b" is foundational.
• Project management / operations: task interdependence, critical-path analysis, bottlenecks, the theory of constraints.
• Supply chains: upstream component availability gates downstream production.
• Logic / language: logical entailment ("A requires B to be true"), semantic presupposition ("the king of France is bald" presupposes a French king).
• Biology: obligate mutualism (one species cannot survive without another), biochemical pathway precursors, host-parasite interactions.
• Institutions / contracts: legal consideration, regulatory preconditions, treaty ratification chains.

Clarity

Dependency names the asymmetric reliance relation itself, distinct from the things it gets confused with. It is not the graph of relations (that is Network); it is not the productive mechanism that links cause to effect (that is Causality); it is not a limit on what is permissible (that is Constraint); it is not the historical accumulation that shapes which relations exist now (that is Path Dependence). What Dependency adds: a directed arrow A→B with a failure-mode commitment — there is a specifiable way A breaks, stalls, or becomes ambiguous when B is unmet. That commitment is what separates a real dependency from a mere correlation, association, or co-occurrence.

Manages Complexity

Dependency gives a system a structure to walk: from any element A, you can ask what does A depend on? and traverse to its prerequisites, then their prerequisites, and so on. This converts an opaque tangle of elements into a navigable graph with five named roles: a dependent element, a relied-on element, a dependency condition (what the relied-on must satisfy), a direction (asymmetric), and a failure mode (what breaks when the condition fails). Once those roles are present, downstream phenomena fall out by topology: chains become transitive reliance; cycles become circular dependencies; many-to-one becomes bottleneck; layered DAGs become architecture. Naming the relation lets the analyst see the topology instead of the elements.

Abstract Reasoning

Dependency supports the counterfactual "if B were removed or violated, A would fail in this specific way." That is the move that lets engineers compute critical paths, lawyers identify contract preconditions, biologists predict cascading extinctions, and logicians track entailment. Across substrates, the same abstract operations apply: take the transitive closure (everything A indirectly depends on), find roots (elements with no upward dependencies), find bottlenecks (single nodes many things depend on), and detect cycles (mutual reliance, which is often a modeling error worth fixing). These operations are substrate-independent because the relation itself is.

Knowledge Transfer

The vocabulary travels intact across domains. A software engineer reading about supply-chain disruption recognizes a build-graph problem; a biologist reading about technology lock-in recognizes obligate mutualism; a lawyer reading about logical entailment recognizes contractual consideration. The transfer is structural, not metaphorical — these are all instances of directed reliance with a failure mode. The biological case (obligate symbiosis, biochemical precursor chains) is especially clean: it shows the pattern with no human institutions in the picture at all, ruling out the suspicion that "dependency" is a software-engineering specialty.

Example

Consider a research paper whose argument depends on Lemma 2. Lemma 2 is the relied-on element; the paper's main result is the dependent element; the dependency condition is that Lemma 2 be true; the direction is asymmetric (the main result needs the lemma, not vice versa); and the failure mode is specifiable — if Lemma 2 has a counterexample, the main result collapses in a documented way. This is a dependency without any causal mechanism: nothing physically causes anything; the reliance is logical. The same five-role pattern applies to a software build (the binary depends on a library), a contract (the obligation depends on a signature), and a food web (the predator depends on the prey). Dependency is the umbrella; causality is the physical-mechanism subtype.

Relationships to Other Primes

Foundational — no parent edges in the catalog.

Children (11) — more specific cases that build on this

• Causality is a kind of Dependency — Causality is a specialization of dependency in which one event productively brings about another with counterfactual modal robustness.
• Entanglement is a kind of Dependency — Entanglement is a kind of dependency: subsystems acquire a directed reliance such that one's state cannot be specified without the other's.
• Infinite Regress is a kind of Dependency — An infinite regress is a kind of dependency chain in which each element depends on a further element of the same kind without termination.
• Task Interdependence is a kind of Dependency — Task interdependence is a specialization of dependency in which the directed reliance is between coupled tasks in a work system.
• Teleconnection is a kind of Dependency — A teleconnection is a kind of dependency in which distant regions are not independent because a shared mechanism couples them.

▸ Show 6 more

Not to Be Confused With

• Not Causality: dependencies can be logical, contractual, or semantic without any productive causal mechanism. "This proof depends on Lemma 2" describes a logical reliance, not a causal process; "the contract depends on signature" is institutional, not physical causation. Causality is one specific kind of dependency (the physically-productive kind); dependency is broader. (Project-06 R21 unanimously committed causality → dependency as subsumption.)
• Not Network: a network is the graph of relations among elements. Dependency is the directed relation that can populate such a graph. Many networks involve dependencies, but not all relations in a network are dependencies (some are correlations, similarities, or symmetric ties).
• Not Constraint: a constraint restricts what is permissible; a dependency requires something be supplied. A dependency can create a constraint (B must hold, restricting the option space) but the two concepts foreground different things: constraints are limits on the search space; dependencies are incoming relations to specific elements.
• Not presupposition: presupposition is a specific kind of dependency in language/logic (one proposition assumed by another); dependency is the broader structural pattern.
• Not Path Dependence: path dependence is the historical-accumulation mechanism that explains how current dependencies came to exist; dependency is the current relation itself. Path dependence usually presupposes some dependency structure; dependency need not be path-dependent (a fresh logical entailment depends on its premises without any history of accumulation).

Notes

Surfaced by ChatGPT Pro's R16 one-shot pass — a genuinely novel contribution to Claude's gap list. The case is strong: task_interdependence, bottleneck, interface, coordination, path_dependence, and many software-architecture nodes use "dependency" as their structural vocabulary but no umbrella prime existed in the catalog. Worth careful consideration of the causality / dependency boundary — the network/constraint distinctions feel clean, but the causality boundary is where the prime has to hold up to scrutiny. The decisive case is the logical/semantic/institutional dependencies where there is no productive causal mechanism: those are dependencies but not causation, so the prime is doing distinct structural work. Load-bearing piece (anti-drift anchor for v2 drafting): "directed reliance with a specifiable failure mode" is the framing that must survive into v2 — losing it lets v2 narrow toward either causality (productive mechanism) or constraint (option-space limit), both of which name something less general than dependency itself. R21 closed causality → dependency as subsumption (unanimous), confirming the root-altitude positioning.