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 one element relies on another being present, prior, compatible, or supplied — a structural asymmetry where A cannot proceed, function, be interpreted, or retain its value unless some condition on B is met, a relation Parnas (1972) made foundational to modular decomposition by treating "module A depends on module B" as the operational criterion governing which design changes propagate. ^[1] The relation has been formalized independently in five distinct intellectual traditions: graph-theoretic dependency analysis in compiler design (Aho, Lam, Sethi, and Ullman 2006), task-precedence modeling in operations research (Kelley and Walker 1959, who introduced the Critical Path Method), logical entailment in formal logic (Tarski 1936), semantic presupposition in philosophy of language (Strawson 1950), and obligate dependency in ecology (Janzen 1980). ^{[2][3][4][5][6]} The fact that these traditions converged on essentially the same structural notion — a directed reliance relation with a specifiable failure mode — without borrowing from each other is the strongest evidence that dependency is a substrate-independent prime rather than a domain-specific construct.

Dependencies can be material (downstream production needs upstream parts, the configuration Lee, Padmanabhan, and Whang (1997) showed amplifies demand variation through the bullwhip effect), informational (a downstream calculation needs an upstream input), temporal (a later event needs an earlier one to have occurred), logical (a theorem needs a lemma), semantic (a referring expression needs a referent, the relation Karttunen (1973) formalized in his account of presupposition projection), or institutional (a contractual obligation needs a triggering condition). ^[7][8] What unifies these is not the content of the relation but its shape: A depends on B, where some specifiable condition on B must hold, and where the violation of that condition impairs A in a documented failure mode. Without the failure-mode commitment, the relation degenerates into mere correlation or co-occurrence — both of which are symmetric and carry no asymmetric reliance.

Dependencies compose. A chain of dependencies — A depends on B depends on C — produces transitive reliance: A also depends on C, even though no direct relation was named. A graph of dependencies produces architecture: layered, modular, hierarchical, or cyclic, with topological sort — formalized in Cormen, Leiserson, Rivest, and Stein's (2009) treatment of directed acyclic graphs — providing the canonical algorithm for linearizing the compositional structure. ^[9] The compositional behavior is what lets analysts walk a dependency structure to compute critical paths, identify bottlenecks, detect cycles, and locate single points of failure — operations that recur in software build systems, project schedules, supply chains, biological pathways, legal-treaty ratification, and proof trees, all instances of the layered-dependency discipline Dijkstra (1968) introduced in his account of the THE-multiprogramming system. ^[10] The directed reliance is the atom; everything downstream is topology.

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.

Structural Signature

Dependency encodes the structural pattern: dependent element → dependency condition → relied-on element → direction → failure mode, the five-role schema that maps directly onto the directed-edge formalism Cormen, Leiserson, Rivest, and Stein (2009) use for dependency-graph algorithms. ^[9] Five named roles must be present for a relation to be a dependency rather than something looser. The dependent element is the thing that needs something. The relied-on element is the thing being needed. The dependency condition specifies what the relied-on element must satisfy (be present, be prior, be compatible, be true, be supplied). The direction is asymmetric: removing the relied-on impairs the dependent, but removing the dependent does not impair the relied-on. The failure mode names how the dependent breaks, stalls, or becomes ambiguous when the condition fails — and this is the commitment that separates a real dependency from a correlation, an association, or a co-occurrence.

Recurring features:

• Directed reliance of one element on another
• Asymmetric prerequisite or precondition relation
• Specifiable failure mode when the condition is unmet
• Transitive composition into chains and graphs
• Five-role structure: dependent, relied-on, condition, direction, failure mode
• Substrate-neutral relation populating dependency networks

The structural insight is robust across substrates: a software import statement, a task waiting on its predecessor, a proof citing a lemma, a referring expression presupposing a referent, an obligate symbiont and its host, a contract clause and its triggering signature — all instantiate the same five-role shape, an isomorphism Dijkstra (1968) anticipated when he argued that the same hierarchical dependency reasoning that organizes an operating system organizes any system whose layers can be reasoned about in isolation. ^[10] Naming the relation gives the analyst something concrete to walk: from any A, ask what does A depend on? and traverse to the prerequisites, then their prerequisites, recursively. This converts an opaque tangle into a navigable directed structure. The topology then yields the familiar derived phenomena: chains become transitive reliance, many-to-one becomes a bottleneck, mutual reliance becomes a cycle (usually a modeling error), and layered DAGs become architecture.

What It Is Not

Dependency is not a graph. A graph is the data structure — the set of nodes and edges — within which dependency relations can be represented. A network can contain many kinds of edges (correlations, similarities, symmetric ties, undirected affiliations), only some of which are dependencies. The graph is the container; the dependency is one kind of contents. Conflating the two leads analysts to assume that any node-and-edge representation captures the asymmetric reliance they care about, which it does not.

Dependency is also not a constraint. A constraint restricts the space of permissible states or actions; a dependency requires that a specific other element be supplied. A budget cap is a constraint; needing parts from a supplier is a dependency. The two can interact — a dependency can create a constraint downstream (B must hold, narrowing the option space) — but they foreground different things. Constraints answer "what is forbidden?"; dependencies answer "what is required?", a grammatical separation Holmes (1881) traced through contract doctrine, where consideration is a required precondition for enforceability rather than a constraint on the bargain's content. ^[11] A system can be heavily constrained yet have few dependencies (a regulated industry with autonomous firms), and heavily dependent yet face few constraints (a long supply chain operating in open markets).

Dependency is not causality, though the boundary is the one most worth careful attention. Causality is the productive, mechanism-mediated, time-asymmetric subtype of directed reliance — B's occurrence produces A's occurrence through a transmission of force, energy, information, or influence across time. Dependency is broader: it includes causality but also covers logical, contractual, and semantic reliance where no productive mechanism is in play. A proof depending on Lemma 2 involves no causal process — the lemma does not make the proof valid in any time-extended productive sense; the dependency is atemporal and constitutive. This is the substrate-furthest test case for the prime, and it is the case that establishes dependency as the umbrella and causality as one specific instance.

Dependency is not a mere correlation or co-occurrence. Two variables can co-occur reliably without one depending on the other (both may depend on a common cause). The directed-reliance commitment requires a specifiable failure mode: there must be a documented way A breaks when B fails. Without that, you have at most a statistical association.

Dependency does not imply tight coupling or fragility. A dependency can be loose (the dependent element degrades gracefully when the condition is unmet), redundant (multiple relied-on elements satisfy the same condition), or substitutable (the dependency condition can be satisfied by any of a class of suppliers). Tight coupling is a property a dependency can have; it is not the dependency itself.

Broad Use

• Software engineering: import graphs, build systems, transitive dependency resolution, package managers, dependency injection, version-conflict resolution, semantic versioning, and "dependency hell" — vocabulary whose modular-decomposition grounding traces to Parnas (1972). ^[1] The dependency vocabulary is so pervasive in software that practitioners sometimes assume it originated there; in fact, the operations-research formalism (PERT, CPM) predates the software usage by roughly a decade (Malcolm, Roseboom, Clark, and Fazar 1959).^[12]
• Project management and operations: task interdependence, critical-path analysis, PERT networks, the theory of constraints (Goldratt 1984), bottleneck identification, Gantt-chart predecessor relations.^[13]
• Supply chains and manufacturing: upstream component availability gates downstream production; just-in-time inventory amplifies dependency exposure; the bullwhip effect propagates demand variation through dependency chains.
• Logic and formal language: logical entailment (A ⊨ B means B depends on A for its truth in any model where A holds), sequent calculus, natural-deduction proofs as dependency trees from premises to conclusion.
• Linguistics and philosophy of language: semantic presupposition (a referring expression depends on the existence of its referent), implicature, anaphora resolution, scope dependency.
• Biology and ecology: obligate mutualism (one species cannot survive without another), biochemical pathway precursors, host-parasite reliance, trophic cascades when an upstream species in a food web is removed.
• Law and institutions: legal consideration (a contractual obligation depends on consideration having been exchanged), regulatory preconditions, treaty ratification chains, the doctrine of severability.
• Economics: factor-input dependency in production functions, complementary goods, network goods whose value depends on the installed base.

Clarity

A core function of "dependency" is to name the asymmetric reliance relation itself, separated cleanly from the things it is regularly confused with — a separation Parnas (1972) sharpened when he argued that a module's dependencies, not its size or its function, are what determine how design changes propagate. ^[1] 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 shaping which relations exist now (that is path_dependence); it is not a prior assumption that a proposition takes for granted (that is presupposition, which is itself one kind of dependency). What dependency adds is the directed arrow A→B together with the 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.

The clarity move is to refuse the operator the temptation to use "depends on" loosely. When a stakeholder says "the rollout depends on stakeholder buy-in," the dependency-aware analyst presses: what specifically does the rollout require buy-in to supply, and what is the documented failure mode if buy-in is absent? If no failure mode can be named, the relation is not a dependency but an association — and treating it as a dependency leads to over-engineering (building escape valves for a relation that does not actually fail in a specifiable way) or to false reassurance (assuming the relation is captured when it is not).

Manages Complexity

Dependency gives a system a structure to walk. From any element A, the analyst asks what does A depend on? and traverses to its prerequisites, then their prerequisites, recursively — the same downward-walking discipline Dijkstra (1968) used to argue that each layer of the THE system could be understood by reference only to the layer immediately below. ^[10] This converts an opaque tangle of elements into a navigable directed graph with five named roles, and once those roles are present, downstream phenomena fall out by topology: chains become transitive reliance, cycles become circular dependencies (almost always a modeling error worth fixing), many-to-one fan-in becomes a bottleneck whose failure cascades widely, and layered DAGs become architecture. Naming the relation lets the analyst see the topology rather than only the elements.

The complexity-management payoff is concrete. A software team confronted with a build that takes two hours can ask "which targets depend on which?" and identify parallelizable subgraphs. A project manager confronted with a slipping deadline can compute the critical path and locate the one task whose delay propagates to the end date. A supply-chain analyst can identify the single supplier whose failure would halt the most downstream production. A logician can compute the minimal set of lemmas needed to prove a theorem. The same operation — walk the dependency structure, compute the closure, find the bottleneck — recurs across all of these, and it is the asymmetric directed reliance that makes the walk meaningful.

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, often the foundational primitives or the supplied inputs), find bottlenecks (single nodes many things depend on, whose failure has wide blast radius), and detect cycles (mutual reliance, which usually indicates either a modeling error or a genuine fixed-point structure that needs special handling). These operations are substrate-independent precisely because the relation itself is.

The counterfactual lift is what makes dependency reasoning powerful even when the actual failure has not yet occurred, an analytical leverage that Cormen, Leiserson, Rivest, and Stein (2009) make algorithmic in their treatment of graph-traversal techniques for closure and reachability. ^[9] A reliability engineer running fault-tree analysis is not waiting for the system to fail; she is enumerating the dependencies and computing which subsets of failures would propagate to system-level failure. A legal scholar reviewing a contract is not waiting for a breach; she is identifying which preconditions, if unmet, would unwind the obligations. A biologist modeling an ecosystem is not waiting for extinction; she is identifying which species, if removed, would cascade through the trophic dependency graph. The dependency vocabulary makes these otherwise-disparate exercises recognizable as instances of a single structural operation.

Knowledge Transfer

The vocabulary travels intact across domains, and this is the empirical case for treating dependency as a prime rather than a domain-specialist term. A software engineer reading about supply-chain disruption recognizes a build-graph problem. A biologist reading about technology lock-in recognizes the structural shape of obligate mutualism. A lawyer reading about logical entailment recognizes contractual consideration. The transfer is structural rather than metaphorical — these are all instances of directed reliance with a specifiable failure mode, and the operations that work in one substrate (walk the closure, find the bottleneck, detect the cycle) work in the others because the relation is the same.

The cleanest cross-substrate case is the logical/semantic dependency, because it contains no productive causal mechanism at all. A proof depends on its premises; a referring expression depends on the existence of its referent; a theorem depends on the lemmas it cites. There is no time-extended energetic process; the reliance is constitutive and atemporal, as Karttunen (1973) made precise for the linguistic case in showing that the presuppositions of a compound sentence are computed from its parts by a context-update procedure that has nothing to do with physical causation. ^[8] If the prime survives this case — if the same five-role structure applies and the same operations remain meaningful — then dependency genuinely extends beyond physics into the formal sciences, which is the test that distinguishes structural primes from domain-bound vocabulary. It does survive. A logician asked "what does this proof depend on?" produces a dependency graph whose nodes are propositions and whose edges represent the reliance of one proposition on another for its derivability; the graph supports the same operations (transitive closure, root-finding, cycle detection) as a software build graph. The substrate-furthest case strengthens rather than weakens the prime.

Examples

Formal/abstract

Logical entailment (Tarski 1936; Gentzen 1935). Consider a research paper whose main theorem depends on Lemma 2. ^[4] Lemma 2 is the relied-on element; the main theorem is the dependent element; the dependency condition is that Lemma 2 be true (i.e., have a valid proof from accepted axioms); the direction is asymmetric (the theorem needs the lemma, not vice versa, and overturning the theorem leaves the lemma untouched); the failure mode is specifiable — if Lemma 2 is shown to have a counterexample, the main theorem's proof is invalidated in a documented way (Tarski's model-theoretic account of entailment makes the failure mode precise: any model that falsifies the lemma also falsifies any derivation that uses the lemma as a premise).^[4][14] This is a dependency without any causal mechanism: nothing physical causes anything; the reliance is logical and constitutive. Mapped back: the five-role pattern is intact even when stripped of any productive causal substrate. This is the substrate-furthest test case for the prime, and it passes — the operations that work on software dependency graphs (transitive closure, bottleneck identification, cycle detection as modeling error) also work on proof trees. The graph-theoretic abstraction that compiler designers use to schedule instructions (Aho, Lam, Sethi, and Ullman 2006) is the same abstraction logicians use to track which lemmas a theorem rests on. The substrate is different; the structural relation is identical.

Critical-path analysis (Kelley and Walker 1959; Malcolm, Roseboom, Clark, and Fazar 1959). A construction project consists of 200 tasks; each task has predecessor tasks it cannot start until they finish. ^[3] The dependent element is the downstream task; the relied-on elements are its predecessors; the dependency condition is that predecessors be completed; the direction is asymmetric (a delayed predecessor delays the downstream task, but a delayed downstream task does not delay its predecessor); the failure mode is specifiable — a one-day slip on the critical-path task propagates one-for-one to the project end date.^[3][12] The critical path is the longest chain of dependencies through the project graph, and its length determines the minimum project duration. The Critical Path Method (CPM) and Program Evaluation and Review Technique (PERT), developed independently in 1957–1959 for the DuPont Nemours plant maintenance program and the U.S. Navy's Polaris missile program respectively, both formalized this dependency-graph reasoning roughly a decade before the software-engineering "dependency" usage became common. Mapped back: the operations-research formalism makes the five-role structure rigorous (tasks as nodes, finish-to-start precedence as edges, slack as the buffer between condition-satisfaction time and dependent-element-start time) and demonstrates that the dependency-walking algorithms (transitive closure, longest path, slack computation) are substrate-independent. The same algorithms applied to software build graphs, scientific workflow DAGs, and proof trees yield the analogous quantities.

Applied/industry

Software build systems (Aho, Lam, Sethi, and Ullman 2006; Lattner and Adve 2004). A modern build system like Bazel, Make, or Ninja represents a project as a directed acyclic graph of build targets, where each target depends on input files and other targets.^[15][16] The dependent element is the build target; the relied-on elements are its inputs and prerequisite targets; the dependency condition is that the inputs exist and the prerequisite targets be up-to-date; the direction is asymmetric (changing an input invalidates the target, but rebuilding the target does not change the input); the failure mode is specifiable — if an input is missing or a prerequisite is stale, the build either fails or produces an incorrect artifact. The build system computes the transitive closure of dependencies, identifies which targets need rebuilding (incremental builds), parallelizes independent subgraphs (multi-core builds), and rejects cycles as malformed specifications. Package managers (npm, pip, cargo, maven) extend the same structure to versioned dependencies with constraint-satisfaction on version ranges. Mapped back: the build-system case is the contemporary canonical instance — it makes the five-role structure operationally visible and demonstrates that the same algorithms (transitive closure, bottleneck identification, cycle detection) recur in industrial practice. "Dependency hell" — the cascade of conflicting version constraints when transitive dependencies disagree — is itself a dependency-graph phenomenon that only makes sense within the prime's vocabulary.

Obligate ecological mutualism (Janzen 1980; Bronstein 1994). The yucca moth (genus Tegeticula) and the yucca plant exhibit obligate mutualism: the moth's larvae feed only on yucca seeds, and the yucca is pollinated only by the moth.^[6][2] The dependent element is each species' reproductive success; the relied-on element is the partner species; the dependency condition is the partner's presence and viable population; the failure modes propagate (extinction of the moth causes the yucca to fail to reproduce, and vice versa); the dependency is so tight that local extinction of one partner reliably precedes local extinction of the other. The case is structurally clean because it contains no human institutions, ruling out the suspicion that "dependency" is a software-engineering specialty smuggled into ecology — biologists who never read a compiler textbook arrived at the same five-role relation through field observation. Mapped back: the biological case validates the prime as substrate-independent in the direction opposite to the logical case. The logical case shows the prime extends upward from physics into formal sciences (no productive mechanism needed); the biological case shows it extends across substrates without requiring human institutions. Both preserve the five-role structure and both support the same dependency-walking operations (transitive closure across a food web, bottleneck identification of keystone species, cycle detection of mutually obligate pairs).

Structural Tensions

T1: Dependency-tracking can become expensive enough to swamp the system it serves. The transitive closure of dependencies in a large software project, a global supply chain, or a long proof can grow combinatorially. Tooling that promises to make every dependency visible (full dependency graphs in package managers, full predecessor relations in project-management software, full citation graphs in academic publishing) can produce so much information that practitioners ignore the output and revert to local heuristics. The prime's analytical power scales with the willingness to traverse the structure, and that willingness is bounded by attention.

T2: Naming a dependency formalizes it and can ossify what was previously informal. A team that has worked together for years has tacit dependencies — knowledge about who consults whom on which questions — that are flexible and renegotiated continuously. When the same dependencies are formalized into a RACI matrix or an org-chart reporting line, the relations become inspectable and accountable, but also more rigid. The act of making dependencies explicit can convert a fluid working arrangement into a brittle contractual one. The same tension appears in software: explicit dependency declarations in a manifest file enable reliable resolution but also commit the project to specific versions and break the implicit flexibility of "use whatever is on the system."

T3: A dependency can be a bug or a feature depending on whose perspective is taken. From an architect's perspective, a tight dependency between two modules is technical debt: it constrains future change, propagates failure, and makes the system harder to reason about. From a domain expert's perspective, the same dependency may be a faithful encoding of a real constraint (these things genuinely cannot be separated without losing meaning). The "should we decouple this?" question often has no general answer — it depends on whether the dependency is a leakage from poor decomposition or a faithful representation of an actual reliance in the domain.

T4: Cycles in a dependency graph are usually treated as errors, but some real systems contain genuine fixed-point reliance. Tooling almost universally treats dependency cycles as malformed: build systems refuse to compile, package managers refuse to install, proof checkers refuse to verify, project schedulers refuse to compute critical paths. This rule works because most cycles are modeling errors. But some domains contain real mutual reliance that resists acyclic representation: monetary systems where trust depends on use which depends on trust; ecosystems where two species are mutually obligate; recursive definitions in mathematics; co-evolving software components. Forcing these into a DAG either loses information or creates artificial asymmetries. The tension is between the algorithmic convenience of acyclicity and the structural honesty of cyclic reliance.

T5: The dependency relation invites the failure-mode question, which can entrench worst-case thinking. Once an analyst is trained to identify dependencies and ask "what is the failure mode if this relied-on element fails?", the natural extension is to add buffers, redundancies, and contingencies for each failure mode. This is the structural source of much defensive engineering. The cost is real: redundant supply lines, duplicate code paths, belt-and-braces legal clauses, exception handlers for cases that never occur in practice. Without dependency reasoning, the system is fragile; with relentless dependency reasoning, the system is over-engineered. The right level of preparation requires judgment that the prime itself does not supply.

T6: Dependency analysis is most reliable in stable substrates, but the value of the analysis is highest in volatile ones. In a stable substrate (a mature software library, an established legal code, a well-characterized biochemical pathway), the dependency structure is known and the analysis is reliable but the payoff is marginal — nothing surprising is likely to be found. In a volatile substrate (a novel system being rapidly built, a startup pivoting, a contested legal frontier, an emerging ecosystem), the dependency structure is partially unknown and may be changing under the analyst's feet; the payoff would be high but the analysis is unreliable. The prime's analytical leverage is concentrated where its inputs are weakest. Practitioners often respond by demanding more documentation upstream, which raises friction and may be resisted; the alternative is iterative dependency discovery, which is slower but tracks the moving substrate.

Structural–Framed Character

Dependency sits at the structural end of the structural–framed spectrum: the directed relation of one element relying on another being present, prior, compatible, or supplied is as bare a structural commitment as the catalog contains. The same notion was formalized independently in compiler design, operations research, formal logic, philosophy of language, and ecology without any of those traditions borrowing from each other — the strongest evidence of substrate-independence the corpus offers.

No domain vocabulary needs to come along; "A depends on B in such a way that violating a condition on B impairs A in a specifiable failure mode" is statable in any field's terms. The prime carries no evaluative weight — dependencies can be load-bearing or fragile, exploited or designed around, but the relation itself is not normatively loaded. Institutional origin reads zero: a theorem depends on a lemma, a downstream chemical reaction depends on an upstream concentration, and an ecological obligate depends on its host with no institution required. Human-practice-bound also reads zero: biological pathways and proof trees are dependencies in exactly the same structural sense as project schedules. Import-vs-recognize is recognition: a software engineer mapping module dependencies, an ecologist mapping obligate-mutualist dependencies, and a logician mapping entailment dependencies are each reading directed-reliance structure already present, not importing a framing. On the spectrum, the verdict is canonical-structural.

Substrate Independence

Dependency is about as substrate-independent as a prime can be — composite 5 / 5 on the substrate-independence scale. The pattern is one substrate-neutral relation: a directed reliance in which the state, action, availability, meaning, or success of one element relies on another being present, prior, compatible, or supplied. Every diagnostic lands at the ceiling. Domain breadth is maximal because directed reliance recurs unchanged across software dependency graphs, project task networks, supply chains, biological obligate relationships, contract law (consideration, precondition), logical entailment, and semantic presupposition. Structural abstraction is at the top because directed reliance is a pure relational property of an ordered pair, expressible without any substantive vocabulary. Transfer evidence is unusually strong: the same relation has been independently formalized in at least five intellectual traditions (graph-theoretic dependency analysis in compilers, task-precedence in operations research, logical entailment, semantic presupposition, and obligate dependency in ecology), and the convergence across those independent formalizations is itself the most direct evidence of substrate independence. The verdict is that dependency is one of the catalog's paradigm structural primes, a clean 5 recognized wherever one element's standing requires that of another.

• Composite substrate independence — 5 / 5
• Domain breadth — 5 / 5
• Structural abstraction — 5 / 5
• Transfer evidence — 5 / 5

Relationships to Other Abstractions

Current abstraction Dependency Prime

Foundational — no parent edges in the catalog.

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

• Causality Prime is a kind of Dependency

  Causality is a specialization of dependency in which one event productively brings about another with counterfactual modal robustness.

• Cross-Boundary Subsidy Prime is a kind of, typical Dependency

  Cross-boundary subsidy is a directional resource flow creating donor-coupling reliance, matching dependency's asymmetric-reliance definition.

• Entanglement Prime 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.

▸ Show 23 more

Neighborhood in Abstraction Space

Dependency sits among the more crowded primes in the catalog (30^th percentile for distinctiveness): several abstractions describe nearly the same structure, so a description that fits it will tend to fit its neighbors too — transporting it usually means disambiguating within this family rather than landing on it exactly.

Family — Structure, Decomposition & Relational Mapping (39 primes)

Nearest neighbors

• Single Point of Failure — 0.75
• Correlation — 0.73
• Substitutability — 0.72
• Dependency Distribution Concentration — 0.72
• Decomposition — 0.72

Computed from structural-signature embeddings · 2026-07-26

Not to Be Confused With

Dependency must be distinguished from Causality, and this is the boundary where the prime has to hold up to scrutiny. Project-06's R21 round closed unanimously on causality → dependency as subsumption, treating causality as the time-asymmetric, mechanism-mediated subtype of directed reliance and dependency as the umbrella. The decisive case is logical entailment, where a proof depends on a lemma with no productive causal mechanism whatsoever — the reliance is atemporal, constitutive, and substrate-formal. Nothing causes the proof to depend on the lemma; the dependency is a feature of the logical relation itself. The same applies to semantic presupposition (a referring expression's reliance on the existence of its referent), contractual consideration (an obligation's reliance on a triggering exchange), and definitional reliance (a term's reliance on the meanings of its constituents). All of these are dependencies; none are causal in the productive-mechanism sense. Causality additionally requires time-asymmetry and the transmission of force, energy, or information across a temporal interval — features that dependency does not require. Every causal relation is a dependency, but not every dependency is causal: the dependency between premise and conclusion is timeless; the causal relation between rain and wet ground is not. Collapsing them would force the catalog either to deny the logical case (damaging formal-sciences coverage) or to stretch causality to cover atemporal constitutive reliance (eroding its commitment to productive mechanism).

Dependency must be distinguished from Network. A network is the graph data structure — nodes and edges. Dependency is a kind of edge that can appear in a graph. The network is the container; the dependency is one possible relation populating it. Networks can carry many edge types: symmetric ties (friendship, similarity, co-occurrence), asymmetric ties (citation, dominance, dependency), weighted ties (correlation strength, flow volume). Collapsing the two would force the false choice between treating every network edge as a dependency (which fails for correlation networks) or requiring every dependency to come with a full graph context (which fails for the two-node case). The clean separation: dependencies populate networks, and operations on dependency-typed networks (topological sort, critical-path computation, transitive closure) work only when the edges carry the asymmetric reliance commitment.

Dependency must be distinguished from Constraint. A constraint restricts what is permissible; a dependency requires that a specific other element be supplied. The grammatical mood differs: constraints forbid ("you cannot exceed this budget," "no two queens may share a row"); dependencies require ("you need this input," "this lemma must be true"). A dependency can create a constraint downstream — if A depends on B, any solution must supply B — but the two foreground different things. Constraints describe the boundary of the feasible region; dependencies describe the directed reliance edges among elements. Some dependency-resolution algorithms encode dependencies as constraints over a version space, but the encoding is a translation between two different structural notions, not an identity.

Dependency must be distinguished from Presupposition. Presupposition is a specific kind of dependency in language or logic — one proposition takes another for granted (the king of France is bald presupposes that France has a king; the dependent assertion fails or becomes ambiguous if the presupposition fails). Dependency is the broader umbrella. Collapsing them would either lift presupposition out of its linguistic-semantic home (where projection behavior, accommodation, and presupposition failure are precisely characterized) or shrink dependency to a linguistic notion that no longer covers software builds, supply chains, or proof trees.

Dependency must be distinguished from Path Dependence. Path dependence is the historical-accumulation mechanism explaining how the current set of dependencies came to exist as it does — early choices, increasing returns, lock-in, and irreversibility produce a present configuration that reflects history rather than current optimality. Dependency is the current relation itself, and it need not be path-dependent: a fresh logical entailment depends on its premises with no history of accumulation, and a newly designed system can have engineered dependencies that were chosen rather than accreted. Path dependence usually presupposes some dependency structure, but the explanatory directions are opposite: path dependence asks "why are the current dependencies these and not others?"; dependency asks "what are the current dependencies and what do they imply?" Path dependence is a mechanism for the origin of certain dependency configurations; dependency is the relation whose origin path dependence sometimes explains.

Solution Archetypes

Solution archetypes in the catalog that build on this prime — directly (this prime is a source ingredient) or as a related prime.

Built directly on this prime (14)

• Controlled Inheritance Propagation: Let descendants receive shared structure by default from a lineage ancestor while requiring every exception to have a scoped, visible, and testable override.
  ▸ Mechanisms (14)
• Definition-Time Context Binding: Bind a behavior unit to the minimum context that defined it so later execution resolves against that context rather than silently inheriting an unrelated ambient environment.
  ▸ Mechanisms (15)
• Demand-Triggered Deferred Evaluation: Represent optional or path-dependent work as a suspended unit, realize only the dependency closure demanded now, and make result sharing, side effects, failure timing, cancellation, lifetime, and first-use latency explicit.
  ▸ Mechanisms (16)
• Distributed Coordination Architecture: Design the outcome, authority, dependencies, interfaces, shared state, timing, commitments, exceptions, and feedback that let independently controlled actors produce a coherent collective result.
  ▸ Mechanisms (13)
• Donor-Coupled Capacity Governance: When a recipient appears viable because a donor/source continuously sustains it across a boundary, make the subsidy explicit, test real capacity, and choose continuation, formalization, transition, or withdrawal safeguards.
  ▸ Mechanisms (9)
• Holonic Autonomy Nesting: Design nested units as autonomous local wholes and dependent parts at the same time, with explicit boundaries, interfaces, escalation paths, and cross-level invariants.
  ▸ Mechanisms (8)
• Layered Defense Gap Decorrelation: Treat every defense layer as imperfect, then prevent catastrophe by finding and breaking the cross-layer alignment of its holes.
  ▸ Mechanisms (8)
• Pivotal Participation Leverage Mapping: Map who or what becomes decisive because the collective outcome fails without it, then manage that pivotal leverage without confusing nominal size with real marginal contribution.
  ▸ Mechanisms (12)
• Selective Legacy Integration: Carry forward what gives a predecessor system knowledge, trust, and identity while redesigning it for the successor context.
  ▸ Mechanisms (10)
• Self-Hosted Bootstrap Construction: Begin with a trusted minimal seed, let each verified stage produce the capability that builds the next, and finish only when the target system can reproduce and operate itself without hidden external support.
  ▸ Mechanisms (15)
• Specialization Boundary and Reintegration Design: Improve efficiency by narrowing roles or niches only where the gains exceed the coordination, brittleness, learning, and reintegration costs.
  ▸ Mechanisms (11)
• Substrate Lineage Risk Audit: Audit the lineage of a borrowed or inherited substrate so hidden origin conditions do not become unowned local risk.
  ▸ Mechanisms (14)
• Use-Time Referent Validation: Verify that the thing an action depends on still exists and is valid at the moment of use, then bind, use, or fail safely.
  ▸ Mechanisms (10)
• Windfall Discipline and Capacity Preservation: When easy value arrives without being earned by current performance, partition the windfall, preserve accountability and practice signals, reinvest in endogenous capacity, and test viability without the windfall.
  ▸ Mechanisms (10)

Also a related prime in 21 archetypes

• Access-Conditioned Bundle Decoupling: Prevent access leverage from forcing unwanted bundled acceptance by testing necessity, unbundling separable conditions, and preserving meaningful refusal, alternatives, or remedies.
• Cascade Pathway Management: Manage chain reactions by tracing how a local change can trigger successive changes and placing observation, damping, breakpoints, buffers, or channeling capacity along the path.
• Commitment Lifecycle Governance: Turn an intention or assertion into a safe basis for reliance by defining what is bound, who owns it, why it is credible, how performance is verified, how change is communicated, and how the commitment ends.
• Conjunctive Path Assurance: Map the condition on every edge of a hazardous path, test the joint states that make the whole route conduct, and preserve an independent break before the target becomes reachable.
• Constraint-Guided Backtracking: Solve a constrained, path-dependent problem by extending a partial solution, testing it early, and undoing the latest failed commitment while preserving still-valid prior work.
• Deferred Fulfillment Placeholder: Create a first-class placeholder for a committed future value so dependent work can proceed, compose, wait, cancel, or fail explicitly before the value exists.
• Dependency Concentration Control: Prevent dependency fragility by measuring where reliance is concentrated and capping, diversifying, or isolating overweight dependency providers before their failure can dominate the system.
• Dependency-Capture Exit Design: Break role-capture incentives by independently verifying the underlying need, measuring durable resolution, transferring capability, and making exit possible without recreating dependency.
• Directed Asymmetry Mapping and Calibration: When two sides of a relation are not interchangeable, make the direction and dimensions of imbalance explicit before choosing symmetric treatment, side-specific treatment, compensation, or containment.
• Duration-Matched Commitment Design: Do not fund short-clock promises with only long-clock resources unless rollover loss, liquid coverage, and rebalancing paths are already designed.

▸ Show 11 more

Notes

Surfaced by ChatGPT Pro's R16 one-shot pass — a genuinely novel contribution to Claude's gap list. 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. The decisive case for the prime's distinct work is the logical/semantic/institutional dependency where no productive causal mechanism is in play — those are dependencies but not causation. Load-bearing piece (anti-drift anchor for v2): "directed reliance with a specifiable failure mode" is the framing that must survive — losing it lets v2 narrow toward causality (productive mechanism) or constraint (option-space limit), both less general than dependency itself. R21 closed causality → dependency as subsumption (unanimous), confirming the root-altitude positioning.

The five-role structure (dependent / relied-on / condition / direction / failure mode) is the operational test for whether a candidate relation is actually a dependency. The failure-mode role is the one most often skipped in casual usage, and skipping it is the source of the loose "depends on" talk that the prime is designed to discipline. When no failure mode can be named, the relation is at most an association.

Dependency reasoning has scale limits. The transitive closure of a real-world dependency graph quickly exceeds human capacity for direct inspection; the compensating moves are summarization (identify the few bottlenecks), tooling (let the machine compute the closure), and modularization (treat sealed-off subgraphs as single nodes).

The prime is intentionally agnostic about whether dependencies are good or bad. A dependency can be load-bearing structural reliance (the lemma the proof needs) or harmful coupling (the legacy module that propagates failure). The structural diagnosis is the same; the normative evaluation depends on whether the dependency is faithful to the underlying domain or an artifact of poor decomposition.

References

[1] Parnas, D. L. "On the criteria to be used in decomposing systems into modules". Communications of the ACM, 15(12), 1053–1058, 1972. Founds modular decomposition on information hiding; treats which modules depend on which as the operational criterion governing how design changes propagate — supports markers 211, 219, 220. ↩

[2] Bronstein, J. L. "Our current understanding of mutualism". The Quarterly Review of Biology, 69(1), 31–51, 1994. Review of mutualism that characterizes obligate mutualism as a tightly coupled bidirectional dependency with cascading failure modes — the obligate-dependency-in-ecology tradition cited in marker 212 (replaces janzen-1980, which defines coevolution, not dependency). ↩

[3] Kelley, J. E., Jr., & Walker, M. R. "Critical-path planning and scheduling". In Proceedings of the Eastern Joint Computer Conference (IRE-AIEE-ACM), Boston, MA, Dec. 1–3, 1959, pp. 160–173. Original formulation of the Critical Path Method: models finish-to-start precedence among dependent activities as a directed graph whose longest path fixes project duration — supports markers 212 and 225. ↩

[4] Tarski, A. "On the concept of logical consequence". In Logic, Semantics, Metamathematics (J. H. Woodger, Trans., 1956, pp. 409–420). Oxford: Clarendon Press. Model-theoretic account of entailment: a conclusion depends on its premises by truth-preservation across all models, so any model falsifying a premise (lemma) falsifies every derivation using it — makes the failure mode precise for markers 212 and 224. ↩

[5] Strawson, P. F. "On referring". Mind, 59(235), 320–344, 1950. Argues referring expressions presuppose (but do not assert) the existence of their referent; presupposition failure yields a truth-value gap rather than falsity — the semantic-presupposition tradition cited in marker 212. ↩

[6] Janzen, D. H. "When is it coevolution?". Evolution, 34(3), 611–612, 1980. Restricts "coevolution" to reciprocal evolutionary change between paired populations. Retained only in the obligate-mutualism Example (alongside bronstein-1994); REMOVED from marker 212 because it characterizes coevolution, not the obligate-dependency relation. (Bibliography/inline-example only.) ↩

[7] Lee, H. L., Padmanabhan, V., & Whang, S. "Information distortion in a supply chain: The bullwhip effect". Management Science, 43(4), 546–558, 1997. Shows how upstream–downstream supply-chain dependency amplifies demand variability through four mechanisms (demand-signal processing, rationing game, order batching, price variation) — supports the material-dependency claim in marker 213. ↩

[8] Karttunen, L. "Presuppositions of compound sentences". Linguistic Inquiry, 4(2), 169–193, 1973. Foundational presupposition-projection paper: a compound sentence's presuppositions are computed from its parts by a context-update procedure, establishing the atemporal, non-causal character of semantic dependency — supports markers 213 and 223. ↩

[9] Cormen, T. H., Leiserson, C. E., Rivest, R. L., & Stein, C. Introduction to Algorithms (3^rd ed.). MIT Press, 2009. Chapter 22 develops topological sort, depth-first search, and reachability over directed acyclic graphs as the algorithmic vocabulary for dependency-graph analysis (transitive closure, cycle detection, critical-path computation) — supports markers 214, 216, 222. ↩

[10] Dijkstra, E. W. "The structure of the THE-multiprogramming system". Communications of the ACM, 11(5), 341–346, 1968. Founds layered architecture: constraining each layer to depend only on the layer below makes hierarchical reasoning tractable, establishing the layered-dependency discipline cited in markers 215, 217, 221. ↩

[11] Holmes, O. W., Jr. The Common Law. Boston: Little, Brown, 1881. Lecture VII–VIII set out the bargain theory of consideration: an obligation is enforceable only if consideration was exchanged, i.e., consideration is a required precondition for enforceability rather than a constraint on the bargain's content — supports the constraint-vs-dependency contrast in marker 218. ↩

[12] Malcolm, D. G., Roseboom, J. H., Clark, C. E., & Fazar, W. "Application of a technique for research and development program evaluation". Operations Research, 7(5), 646–669, 1959. Original PERT paper from the U.S. Navy's Polaris program; developed independently of CPM and formalizes probabilistic dependency-graph scheduling — supports the PERT/CPM precedence claims in the Examples section (markers 224–225 region) and Broad Use. ↩

[13] Goldratt, E. M., & Cox, J. The Goal: A Process of Ongoing Improvement. Great Barrington, MA: North River Press, 1984. Introduces the Theory of Constraints: in a chain of dependent operations the bottleneck (single highest-fan-in node) governs throughput — supports the theory-of-constraints/bottleneck reference in Broad Use. ↩

[14] Gentzen, G. "Untersuchungen über das logische Schließen" [Investigations into Logical Deduction]. Mathematische Zeitschrift, 39, 176–210, 405–431, 1935. Founds natural deduction and the sequent calculus; represents proofs as trees whose nodes depend on parent nodes for derivability — cited inline alongside tarski-1936 on the proof/lemma dependency in the Examples section (marker 224). ↩

[15] Aho, A. V., Lam, M. S., Sethi, R., & Ullman, J. D. Compilers: Principles, Techniques, and Tools (2^nd ed.). Pearson/Addison-Wesley, 2006. The "Dragon Book": develops graph-theoretic dependency analysis (data/control dependence, DAGs) used for instruction scheduling and optimization — the compiler-design tradition cited in marker 212 and the software-build examples. ↩

[16] Lattner, C., & Adve, V. "LLVM: A compilation framework for lifelong program analysis & transformation". Proceedings of the International Symposium on Code Generation and Optimization (CGO), 75–86, 2004. Develops dependency-graph data structures (SSA-based use-def chains) reused across compilation stages — cited inline in the software-build-systems example. ↩

[17] Baldwin, C. Y., & Clark, K. B. Design Rules: The Power of Modularity (Vol. 1). MIT Press, 2000. Theory of modular design built on design rules that decouple module-internal decisions from interdependencies across modules. (Bibliography-only.)

[18] Simon, H. A. "The architecture of complexity". Proceedings of the American Philosophical Society, 106(6), 467–482, 1962. Classic account of near-decomposability: complex systems are organized into nearly independent subsystems with sparse cross-dependencies. (Bibliography-only.)

[19] Ulrich, K. T. "The role of product architecture in the manufacturing firm". Research Policy, 24(3), 419–440, 1995. Defines product architecture via the mapping from function to components and the interfaces (dependencies) between them. (Bibliography-only.)

[20] Sánchez, R., & Mahoney, J. T. "Modularity, flexibility, and knowledge management in product and organization design". Strategic Management Journal, 17(S2), 63–76, 1996. Argues standardized interfaces embed coordination, so module dependencies need not be actively managed once interfaces are fixed. (Bibliography-only.)

[21] MacCormack, A., Baldwin, C., & Rusnak, J. "Exploring the duality between product and organizational architecture: A test of the 'mirroring' hypothesis". Research Policy, 41(8), 1309–1324, 2012. Empirically tests whether product dependency structure mirrors the organization's communication structure. (Bibliography-only.)

[22] Meyer, B. Agile!: The Good, the Hype and the Ugly. Springer, 2014. Critical assessment of agile methods, including their handling of architectural dependencies and coupling. (Bibliography-only.)

[23] Gamma, E., Helm, R., Johnson, R., & Vlissides, J. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1994. Catalog of 23 patterns; several (e.g., Dependency Inversion via abstractions, Observer) manage object dependencies. (Bibliography-only.)

[24] McIlroy, M. D. "Mass produced software components". In Software Engineering: Report of a Conference Sponsored by the NATO Science Committee, Garmisch, Germany, Oct. 1968, pp. 138–155. Proposes reusable component families whose users depend on stable interface specifications. (Bibliography-only.)

[25] Sommerville, I. Software Engineering (9^th ed.). Addison-Wesley/Pearson, 2010. General software-engineering text covering dependency management, coupling/cohesion, and architectural layering. (Bibliography-only.)