Weighted Dependency Graph¶
Modeling and mapping tool — instantiates Dependency Concentration Control
Represents every dependency as a weighted, directed edge so that overweight providers and shared upstreams stop hiding behind a long, flat list of names.
A dependency list flatters you: forty names look like forty independent bets. Weighted Dependency Graph replaces the list with a model — nodes for providers, services, regions, or credentials, and weighted directed edges for how much reliance actually flows to each. Its defining move is to collapse shared upstreams into shared nodes, so that nine "independent" vendors that all route through one platform stop appearing nine times and instead show up as nine edges converging on a single fat node. Where a roster hides concentration behind plurality, the graph makes concentration a visible shape — a load-bearing node, a common ancestor two hops up — before any number is computed. It is the representation substrate the rest of the archetype reads from.
Example¶
A payments platform inventories ≈40 third-party and internal dependencies and feels comfortably diversified. Building the weighted graph tells a different story. Each edge is weighted by its share of checkout-critical requests, and the model traces one hop upstream: three vendors the team thought were unrelated — fraud scoring, identity verification, and transactional messaging — all sit downstream of the same edge/DNS provider, and roughly 70% of checkout-critical weight funnels through a single internal API-gateway node. The list said "forty"; the graph shows one gateway and one shared upstream carrying most of the real risk. Those two nodes, not the forty names, become the targets the measure, cap, and rebalance steps go to work on.
How it works¶
- Draw the population boundary. Decide what counts as a node and what is out of scope (internal services? nth-party subprocessors?) — the boundary is a modeling choice that determines what concentration you can even see.
- Weight the edges in one unit. Every edge carries an exposure weight in a consistent provider exposure unit (request share, revenue-at-risk, spend), so providers are comparable rather than merely listed.
- Collapse shared upstreams. Trace edges transitively and merge common ancestors into shared nodes, so correlated "alternatives" reveal themselves as topology instead of staying hidden.
- Keep it queryable. It is a live model you interrogate ("what fails if this node dies?"), not a one-off slide — which is what separates it from a static architecture diagram.
Tuning parameters¶
- Node granularity — provider vs. product vs. region vs. credential. Finer nodes surface hidden common-mode sharing but multiply the graph and its upkeep.
- Edge-weight basis — what "reliance" means: traffic share, revenue-at-risk, spend, or request count. The basis decides which node looks fat.
- Transitive depth — how many hops upstream you chase shared ancestry. Deeper finds fourth- and fifth-party common mode but needs data you may not have.
- Boundary scope — internal-only vs. full nth-party. Wider catches subprocessor concentration but costs discovery effort.
- Refresh source — a hand-drawn snapshot vs. a live feed from telemetry or a CMDB; the latter is what keeps the graph from quietly rotting out of date.
When it helps, and when it misleads¶
Its strength is that it turns single points of failure and common upstreams into something you can see — the plurality illusion dissolves the moment weighted edges pile onto one node.[n1] It is the input every other mechanism here consumes: you cannot measure, cap, or rebalance a concentration you have not first mapped.
Its failure mode is that a graph is only as honest as its edges, and the most dangerous error is not a wrong weight but a missing edge — an unmapped shared subprocessor that leaves correlated providers looking independent, which is exactly the illusion the graph exists to break. The classic misuse is reading node count as safety ("look how many dependencies we have") when the weight is concentrated, or building the graph once and trusting a picture that reality has since moved past. The discipline that guards against this is to weight edges rather than count nodes, to trace transitive upstreams even when it is tedious, and to source the graph from live data so it stays true.
How it implements the components¶
Weighted Dependency Graph fills the mapping-and-inventory side of the machinery — the components that represent reliance before anyone judges it:
dependency_population_boundary— its node set and inclusion rules are the boundary of what is under concentration control.weighted_dependency_inventory— the weighted edge set is the inventory itself, in one queryable place rather than scattered across spreadsheets.provider_exposure_unit— each edge carries a weight in a single, consistent exposure unit, making otherwise incomparable dependencies comparable.
It does not reduce the graph to a single concentration figure — that is Top-K Exposure Share — nor judge whether shared upstreams are genuinely correlated (common_mode_dependency_profile, independence_evidence_check), which is the Common-Mode Dependency Audit's work; the graph supplies the weighted structure both of those read from.
Related¶
- Instantiates: Dependency Concentration Control — the graph is the map the whole appraisal is drawn on.
- Sibling mechanisms: Top-K Exposure Share · Effective Independent Provider Count · Dependency Concentration Heatmap · Common-Mode Dependency Audit · Dependency Concentration Stress Test · Concentration Cap Policy · Multi-Sourcing Rule · Provider Load Split Table · Portability Checklist · Substitution Drill · Residual Concentration Risk Register
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Weighted Dependency Graph operates as a static representation, map, specification, schema, or prospective plan that externalizes information because it represents every dependency as a weighted, directed edge so that overweight providers and shared upstreams stop hiding behind a long, flat list of names.
Independent corroboration: The frozen evidence defines Weighted Dependency Graph as 'Represents every dependency as a weighted, directed edge so that overweight providers and shared upstreams stop hiding behind a long, flat list of names', so its operative form is Representation, Specification & Plan.
Nearest alternative: Analysis, Modeling & Optimization — Weighted Dependency Graph includes features of an analytical, modeling, inference, comparison, or optimization procedure that derives insight or a solution, but its defining operation is a static representation, map, specification, schema, or prospective plan that externalizes information.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Data Science & Analytics
Origin pattern: Single lineage
Present-day reach: Universal
Rationale: Vanunu et al., Associating Genes and Protein Complexes with Disease via Network Propagation documents that network science propagates weighted evidence through graph topology to score connected nodes. This is direct, mechanism-specific evidence for data science as the best-evidenced historical home of the operation—Represents every dependency as a weighted, directed edge so that overweight providers and shared upstreams stop hiding behind a long, flat list of names.—rather than evidence merely that the operation is useful there. The retained alternates record genuine adjacent lineages; later portability is represented separately by domain_reach=universal.
Related originating lineages:
- Computer Science & Software Engineering — Computer science and software-engineering practice supplies a parallel or contributing lineage for the mechanism's defining operation: represents every dependency as a weighted, directed edge so that overweight providers and shared upstreams stop hiding behind a long, flat list of names.
- Mathematics — Mathematics supplies a historically relevant adjacent lineage or formative practice for the operation—Represents every dependency as a weighted, directed edge so that overweight providers and shared upstreams stop hiding behind a long, flat list of names.—but the adjudicated evidence more directly locates the defining lineage in data science.
- Operations Research — Operations research's allocation, scheduling, optimization, and decision-analysis tradition contributes a separate formative lineage to the mechanism's weighted dependency graph logic.
- Organizational & Management Science — Organizational design, management, and operational governance supplies a parallel or contributing lineage for the mechanism's defining operation: represents every dependency as a weighted, directed edge so that overweight providers and shared upstreams stop hiding behind a long, flat list of names.
- Statistics & Experimental Design — Statistics, experimental design, and measurement theory supplies a parallel or contributing lineage for the mechanism's defining operation: represents every dependency as a weighted, directed edge so that overweight providers and shared upstreams stop hiding behind a long, flat list of names.
Review resolution: The blind reviewers disagree on primary lineage (mathematics versus data_science). The defining operation is: Represents every dependency as a weighted, directed edge so that overweight providers and shared upstreams stop hiding behind a long, flat list of names. The researched Vanunu et al., Associating Genes and Protein Complexes with Disease via Network Propagation establishes that network science propagates weighted evidence through graph topology to score connected nodes. That source therefore supports data science as the historical origin. mathematics remains in the uncapped alternates where it contributes a formative practice, but application or governance is not itself proof of origin. origin_mode=single_lineage records lineage construction; domain_reach=universal separately records later applicability.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
Notes¶
The graph is deliberately descriptive, not normative: it shows where reliance concentrates but sets no limits and triggers no action. Wiring it to a live source (telemetry, a CMDB, contract data) is what separates a control that stays true from a diagram that was accurate the day it was drawn.
[n1] A single point of failure is a component whose loss halts the whole system; concentration is its distributional form — many nominal dependencies quietly collapsing onto one load-bearing node. Surfacing such nodes as shared vertices is the graph's reason for existing. ↩