Dependency Exposure¶
Reveal hidden dependencies so risks, obligations, failure paths, and coordination needs become visible before they cause failure.
The Diagnostic Story¶
Symptom: A failure in one place cascades into systems that were thought to be unrelated. A rollout or migration keeps hitting blockers that nobody saw in the planning documents. A key process stops the moment one person, vendor, or dataset becomes unavailable. Postmortems repeatedly conclude that 'an assumption turned out to be wrong,' but the assumption was never written down.
Pivot: Surface the dependency relations that were previously implicit or hidden, classify each by criticality and the evidence that supports it, assign accountable ownership, and connect the exposed dependencies to monitoring, contingency planning, or redesign rather than leaving them as entries in a static inventory.
Resolution: Critical dependencies are named, typed, and owned; failure paths are connected to decisions rather than buried in postmortems. Change impact assessment becomes more reliable because planners can see what they are relying on, and sensitive exposure is governed rather than left implicit.
Reach for this when you hear…¶
[platform engineering] “We didn't know our auth service depended on that third-party lookup until it went down and took login with it.”
[supply chain] “We thought we had two suppliers for that component but they both source from the same factory.”
[public health] “The whole reporting pipeline breaks if the lab coordinator is out sick because nobody else has her credentials.”
When This Archetype Applies¶
Partial catalog groundingSome structural conditions are represented by existing abstractions, but no sufficient condition set is fully represented.
Diagnostic problem
A system appears independent or stable while an unseen directed dependency with a specifiable failure mode can disrupt its outcome.
What this problem means
The structural problem is false independence. The focal system is treated as if it can be understood alone, but its real behavior depends on hidden relations to other actors, resources, components, conditions, or assumptions. The hidden relation may be technical, social, contractual, logistical, legal, data-based, cognitive, or environmental.
This produces characteristic failures. A software team removes a service and discovers that a legacy report still calls it. A public agency announces a policy whose local implementation depends on county staffing that does not exist. A manufacturer thinks it has many products but later discovers they share one fragile supplier. A hospital process appears standardized but depends on one experienced coordinator’s informal knowledge. A model output seems automated but depends on an upstream data refresh and an undocumented imputation rule.
The root tension is that dependency visibility is valuable but costly and potentially sensitive. Too little exposure creates fragility and surprise. Too much exposure can create mapping burden, false confidence, security risk, blame, or disclosure of vulnerable human labor. The archetype works only when exposure is scoped, evidenced, and connected to action.
Show the applicability expression
Applicability expression6 distinct conditions
groundedpartly groundedopen
Equivalent to the 5 condition sets it replaces, with 4 duplicate condition cards removed.
1Required in every casenumbered 1–1
These hold no matter which pattern applies.
Failure-bearing directed dependency · open
The hidden or opaque relation is a directed dependency whose relied-on element has a specifiable disruptive failure mode.
This condition preserves a load-bearing part of the diagnostic problem that was not captured by a source-condition atom. It remains explicit because omitting it would weaken the sufficient condition set.
5At least one of theselettered A–E
Any single one of these completes the pattern.
Hidden coupling · grounded
A coupling relation is hidden.
The source archetype describes the situation as follows: Hidden coupling. The normalized requirement above isolates the load-bearing portion used in this condition set.
False independence · grounded
Elements are falsely treated as independent.
The source archetype describes the situation as follows: False independence. The normalized requirement above isolates the load-bearing portion used in this condition set.
Opaque supplier dependency · grounded
A supply chain or vendor relation is opaque.
The source archetype describes the situation as follows: Supply chain or vendor opacity. The normalized requirement above isolates the load-bearing portion used in this condition set.
Fragile load-bearing assumption · grounded
A load-bearing assumption is fragile.
The source archetype describes the situation as follows: Assumption fragility. The normalized requirement above isolates the load-bearing portion used in this condition set.
Ownerless dependency · open
A dependency exists without a clear owner.
The source archetype describes the situation as follows: Unowned dependency. The normalized requirement above isolates the load-bearing portion used in this condition set.
Other requirements and context (3)
Why these sit outside the expression
Supporting context — it may accompany or help interpret the situation, but it is not a load-bearing condition in a sufficient diagnostic set.
Supporting contextChange impact uncertainty.
The source states: Change impact uncertainty. The normalized contextual consideration is: Change impact uncertainty. It helps interpret the situation or strengthens the practical case for examining the archetype.
Supporting contextSingle point of failure suspicion.
The source states: Single point of failure suspicion. The normalized contextual consideration is: Single point of failure suspicion. It helps interpret the situation or strengthens the practical case for examining the archetype.
Supporting context groundings
The impact of a change is uncertain.
domainCausal Inference— Infer the effect of changing X on Y from data by fixing a causal estimand and defending an identification design or assumption that separates that effect from noncausal association, then quantify its uncertainty and scope.
Coverage
4 of 6 conditions grounded · 2 open.
Mechanisms / Implementations¶
- Architecture Dependency Review: A gate placed before migrations, launches, and deprecations that forces the technical, data, and operational dependencies a proposed change would touch into the open before the change ships.
- Assumption Log: Makes the unstated premises a plan silently rests on into an explicit, revisable list — each with its confidence and a trigger to revisit it when reality drifts.
- Contract and SLA Review: Reads the contracts and service-level agreements behind external providers to expose what is actually guaranteed, what happens on breach, and how little recourse the fine print really leaves.
- Critical Dependency Dashboard: A live board that watches the handful of highest-criticality dependencies and lights up the moment one degrades, drifts stale, or nears a deadline — turning a one-time map into continuing observability.
- Dependency Graph: Draws the system's depends-on relations as nodes and directed edges so concentration, chains, and single points of failure become visible at a glance.
- Dependency Registry: The durable system of record for dependencies — one governed entry per dependency carrying its owner, its criticality, and its next review date, so nothing important stays unowned or unrevisited.
- Dependency Review Workshop: Puts maintainers, users, and domain experts in one room to surface the dependencies that live only in people's heads — the tacit handoffs and workarounds no document records — and to claim owners for them on the spot.
- FMEA Dependency Table: Adapts failure mode and effects analysis to dependencies — scoring each one's failure by severity, likelihood, and detectability to produce a ranked, mitigation-prioritized list rather than a flat inventory.
- Impact Analysis: Traces the blast radius of one specific dependency failing or changing — what breaks first, who is hit, how fast, and what substitutes remain — turning a depends-on relation into a concrete consequence.
- Software Bill of Materials: A machine-generated, itemized inventory of every software component and version inside a build — direct and transitive — so a vulnerability, license, or end-of-life question can be answered from a record instead of a scramble.
- Supply Chain Mapping: Traces physical dependencies upstream through multiple supplier tiers — parts, materials, facilities, transport routes, geographies — to reveal the hidden convergence that a direct-vendor view can never see.
- Vendor Risk Map: Connects each external provider to the services, data, and outcomes riding on it, rates the consequence of its failure, and names an owner and a fallback — turning a vendor list into a governed risk picture.
Related Abstractions¶
Abstractions this archetype builds on — directly (a source ingredient) or as a related pattern. Links follow the typed catalog namespace.
Built directly on (3)
- Coupling: Interdependence among subsystems.
- Observability: Infer internal state externally.
- Relation: Describes associations or dependencies.
Also references 11 related abstractions
- Accountability: Responsibility for actions.
- Fault Tolerance: Continue operating under failure.
- Network: Models interactions between components.
- Redundancy: Duplicate critical components.
- Resilience: Absorb shocks and adapt.
- Resource Management: Allocation of finite assets.
- Robustness: Maintain functionality under stress.
- Systemic Fragmentation: Siloed subsystems.
- Task Interdependence: Tasks rely on each other.
- Transparency: Open processes.
Variants¶
Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.
Supply-Chain Dependency Exposure · domain variant · recognized
Expose suppliers, logistics paths, facilities, materials, geopolitical exposures, and contractual dependencies that can disrupt delivery or production.
Software Dependency Exposure · domain variant · recognized
Expose libraries, services, APIs, infrastructure, data feeds, versions, licenses, maintainers, and security dependencies that software relies on.
Assumption Dependency Exposure · risk or failure variant · recognized
Expose plans, models, forecasts, policies, or designs that depend on untested assumptions rather than visible resources or actors.
Human Role Dependency Exposure · domain variant · recognized
Expose dependency on particular people, tacit knowledge, role coverage, informal workarounds, approvals, or relational labor.
Data Dependency Exposure · domain variant · recognized
Expose datasets, data quality assumptions, upstream transformations, model inputs, freshness constraints, and downstream uses that decisions or systems depend on.
Editorial Notes¶
Problem Classification¶
Classification: Observability, Measurement & Feedback Gaps → Hidden State, Structure & Trajectory Visibility
Problem kernel: hidden dependencies make the system appear falsely independent
Rationale: The earliest necessary condition is that components, resources, suppliers, approvals, data, assumptions, and processes supporting outcomes are invisible, making the system appear more independent than it is. Dependency concentration would require nominal alternatives sharing one upstream cause or one provider carrying most reliance, neither of which is necessary to the broader hidden-dependency problem.
Boundary considered: Fragility, Failure & Continuity Risk → Dependency Concentration & Common-Mode Loss
Why this classification prevailed: Hidden-state visibility concerns unknown reliance of any shape; dependency concentration concerns known or inferable reliance clustered so one cause can remove multiple paths together.
Review outcome: Adjudicated after independent review; high confidence.