Part-Whole Dependency Map¶
Structural model — instantiates Part-Whole Unity Criterion Design
Diagrams the relations and boundaries among candidate parts so the strength and shape of their coupling is visible before any verdict.
Whether parts form one whole often turns on a structure that no list of parts can show: which parts depend on which, how tightly, and where the dense clusters give way to sparse gaps. The Part-Whole Dependency Map makes that structure visible. It renders the candidate parts as nodes and the chosen binding relation as edges — call links, supply dependencies, control lines, references — and draws where the coupling is dense enough to suggest a container boundary and where it thins into a natural seam. It is a diagram, not a verdict: it lays out the shape of the coupling so a threshold test can be applied intelligently and a boundary drawn where the structure actually separates, rather than where an org chart or schema imagined it. It shows the relation's topology; it does not set the cutoff and it does not enumerate the parts.
Example¶
A manufacturer sells an espresso machine and wants to know whether it is one product or a bundle of independently-serviceable units. The dependency map plots the parts — boiler, pump, grinder, portafilter group, control board — and draws the binding relation functional and control dependency: the control board drives boiler, pump, and group as one coordinated cycle (dense mutual edges), while the grinder only shares a power rail and a housing (a single thin edge). The map immediately shows two coupling densities: a tightly-bound brew subsystem and a loosely-attached grinder. Where the edges thin between them, the map marks a candidate boundary. This is exactly the input the threshold test needs — it can now ask "is the grinder inside or outside the product boundary?" against a visible seam rather than a guess, and the boundary the map proposes becomes the container within which coupling is later measured.
How it works¶
- Place the candidate parts as nodes and draw the selected binding relation as directed or weighted edges, one edge per real dependency.
- Weight the edges by coupling strength so dense and thin regions are distinguishable, not just present/absent.
- Detect the seams — the sparse cuts where the graph nearly separates — and mark them as candidate container boundaries.
- Expose sub-clusters and bridges, so nested wholes and single load-bearing links are visible before anyone renders a verdict.
Tuning parameters¶
- Edge inclusion threshold — how weak a dependency still earns an edge; including faint links shows more structure but clutters the seams, pruning them sharpens boundaries but can hide a real bridge.
- Weighting scheme — how coupling strength is quantified (frequency, criticality, bandwidth); different schemes move where the seams appear.
- Boundary-drawing rule — how sparse a cut must be to be marked a boundary; loose rules propose many small wholes, tight ones lump.
- Layout grain — the node granularity inherited from the inventory; coarser nodes hide intra-part structure, finer ones can overwhelm the picture.
When it helps, and when it misleads¶
Its strength is making coupling legible: a good map turns "these feel related" into a visible topology where dense cores, thin seams, and load-bearing bridges can be seen and argued about — and it exposes the mismatch between where a real whole's coupling lies and where administrative boundaries were drawn, the archetype's fragmentation symptom. It operationalizes coupling and cohesion[n1]: high internal cohesion with low external coupling is exactly the visual signature of a genuine whole.
Its failure mode is that a map is only as honest as its edges: omit an inconvenient dependency and a seam appears where none exists; over-draw faint links and everything looks like one blob. Because the picture is persuasive, a selectively-drawn map can manufacture whatever boundary its author prefers. The classic misuse is treating the diagram as the verdict — "look, two clusters, therefore two wholes" — when the map is only the input a threshold still has to judge. The guarding discipline is to derive edges from a fixed relation definition rather than by eye, and to hand the seams to the threshold test rather than declaring them boundaries directly.
How it implements the components¶
unity_relation_specification— it renders the chosen binding relation as a weighted topology across all candidate parts, making the relation's actual distribution visible.boundary_or_container_marker— it detects the sparse seams in that topology and marks them as candidate container boundaries for the whole under test.
It does NOT implement candidate_part_inventory — the parts it plots are enumerated by its nearest twin the Part Inventory and Granularity Review, which lists the parts while this map draws the relations among them — and it does NOT implement unity_threshold_condition, the cutoff applied to the seams it exposes, which is the Wholehood Threshold Test's.
Related¶
- Instantiates: Part-Whole Unity Criterion Design — makes the coupling structure the criterion is applied to visible.
- Consumes: Part Inventory and Granularity Review — needs the enumerated parts before it can map dependencies among them.
- Sibling mechanisms: Unity Test Specification Sheet · Part Inventory and Granularity Review · Unity Relation Selection Checklist · Wholehood Threshold Test · Borderline Whole Review Protocol · Unity Verdict Decision Log · Unity Reassessment Trigger
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Part-Whole Dependency Map operates as a static representation, map, specification, schema, or prospective plan that externalizes information because it diagrams the relations and boundaries among candidate parts so the strength and shape of their coupling is visible before any verdict.
Independent corroboration: The frozen evidence defines Part-Whole Dependency Map as 'Diagrams the relations and boundaries among candidate parts so the strength and shape of their coupling is visible before any verdict', so its operative form is Representation, Specification & Plan.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Systems Thinking & Cybernetics
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Universal
Rationale: Part-Whole Dependency Map is most directly rooted in systems thinking and cybernetics' treatment of feedback, control, emergence, and multilevel system behavior. The lineage fits its defining practice: Diagrams the relations and boundaries among candidate parts so the strength and shape of their coupling is visible before any verdict.
Related originating lineages:
- Computer Science & Software Engineering — The emphasized coupling-and-cohesion topology descends from structured software design and module architecture.
- Engineering & Design — Part-Whole Dependency Map also draws materially on engineering and design's traditions of specification, testing, reliability, control, and physical-system construction, which shaped this mechanism rather than merely adopting it as an application.
- Philosophy — Mereology supplies the underlying question of when related parts constitute a genuine whole.
Review resolution: Authoritative-source research resolves the primary-origin disagreement in favor of systems cybernetics. NASA Systems Engineering Handbook documents the formative practice or theory represented here. The retained alternate domains identify material co-development or translation, while current applicability is recorded separately as domain_reach=universal; origin_mode=cross_disciplinary_synthesis describes the historical relationship among lineages.
Attribution caveat: The map generalizes a software criterion into a domain-wide part-whole diagnostic.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; medium confidence.
Sources consulted:
Notes¶
[n1] Coupling and cohesion — from structured software design, the ideas that elements of one module should relate tightly (high cohesion) while modules relate loosely (low coupling). High internal cohesion with low external coupling is the structural signature of a genuine whole. ↩