Wholes, Parts, and Interdependence

Last Updated June 1, 2026

A system is not only a collection of parts. It is a whole formed by relationships among parts. This is one of the most important starting points in systems thinking, and also one of the easiest to misunderstand. The whole does not float above the parts as something mystical or vague. Nor are the parts meaningless by themselves. Systems thinking studies how parts retain their own properties while also taking on new significance through their relationships, dependencies, roles, feedback effects, boundaries, and shared conditions.

To understand a system, one must ask how the whole and the parts shape one another. A city is made of neighborhoods, infrastructure, institutions, people, economies, ecosystems, laws, histories, and technologies. Yet the city is not reducible to any one of those parts. A school is made of students, teachers, administrators, families, curriculum, funding, buildings, policy, assessment systems, transportation, and community context. Yet the school is not merely the sum of those components. A living organism is made of cells, tissues, organs, regulatory pathways, immune responses, energy flows, and environmental exchanges. Yet life emerges through organized interdependence.

This article examines the relationship between wholes, parts, and interdependence as a foundation of systems thinking. It explains why reductionist analysis is often useful but incomplete, why isolated optimization can damage the whole, why context changes the meaning of parts, and why interdependence is central to ecological, institutional, technological, organizational, and social life. It also introduces practical methods for analyzing part-whole relationships without dissolving individual agency, material specificity, or local experience into vague claims about “the system.”

The Part-Whole Problem in Systems Thinking

The part-whole problem asks how individual components relate to the larger system of which they are part. This problem appears in many fields. In biology, one asks how cells, organs, organisms, and ecosystems relate. In sociology, one asks how individuals, groups, institutions, and societies relate. In economics, one asks how households, firms, markets, states, and ecological constraints relate. In infrastructure, one asks how assets, networks, services, operators, users, and governance systems relate. In technology, one asks how hardware, software, data, users, organizations, markets, and regulation relate.

Systems thinking does not answer the part-whole problem by choosing only one level. It rejects two opposite errors. The first error is reductionism: explaining the whole entirely by decomposing it into parts while ignoring relationships, feedback, context, emergence, and system-level behavior. The second error is vague holism: speaking about the whole as if parts, mechanisms, evidence, agency, and material detail no longer matter.

A serious systems approach holds both levels together. It studies parts carefully, but it does not assume that the behavior of the whole can be predicted by studying parts in isolation. It studies wholes, but it does not turn “the system” into an abstract force detached from concrete structures, actors, resources, and relationships.

The practical question is not whether to study the parts or the whole. The question is how to study their relationship. What does the part contribute to the whole? What does the whole require from the part? How does the part’s behavior change because of its position in the whole? How does the whole change when the part changes? Which relationships matter most? Which dependencies are visible? Which are hidden?

This is why part-whole analysis is foundational for systems thinking. It teaches that neither isolation nor abstraction is enough. The unit of analysis is not only the part. It is the part-in-relation.

Back to top ↑

Why the Whole Is Not Merely the Sum of Its Parts

The phrase “the whole is greater than the sum of its parts” is familiar, but it is often used casually. In systems thinking, the phrase points to a precise idea: when parts interact, they can produce properties, behaviors, risks, capacities, or meanings that do not exist in the parts separately. The whole is not greater in a mystical sense. It is different because relationship changes behavior.

Consider language. A sentence is made of words, but the meaning of the sentence is not found by listing the dictionary definition of each word separately. Syntax, sequence, context, emphasis, tone, and shared cultural understanding shape meaning. The parts matter, but their arrangement matters too.

Consider a traffic jam. No single car is a traffic jam. The jam emerges from many vehicles interacting under conditions of road capacity, speed variation, lane changes, driver reaction time, bottlenecks, signals, weather, land use, and travel demand. A traffic jam is a whole-system behavior produced by many parts in relation.

Consider public trust. Trust is not located in one agency, one law, one speech, one metric, or one citizen. It emerges from repeated interactions among institutional performance, transparency, accountability, historical memory, media systems, service quality, fairness, enforcement, and public experience. Trust is an accumulated system property.

Whole-system properties often include:

• Emergence: new behavior arises from interaction among parts.
• Coordination: parts produce outcomes together that none can produce alone.
• Constraint: the whole limits or channels what parts can do.
• Identity: parts take on roles within the larger arrangement.
• Resilience: the whole absorbs disturbance through distributed relationships.
• Fragility: the whole can fail when interdependencies become brittle.
• Meaning: the significance of a part changes depending on its place in the system.

This equation is conceptual rather than literal. It does not mean parts are irrelevant. It means summation alone is not explanation. A list of parts tells us what exists. A systems analysis asks how those parts are organized, how they interact, what they produce together, and what properties emerge from their interdependence.

The whole can also be less than the sum of its parts. A poorly organized institution can suppress the intelligence, creativity, capacity, and judgment of the people within it. A bureaucracy can convert skilled professionals into procedural actors. A broken information system can prevent competent teams from coordinating. A toxic culture can reduce the contribution of talented individuals. Systems thinking therefore does not romanticize wholes. It asks whether the whole amplifies, organizes, constrains, distorts, or depletes the capacities of its parts.

Back to top ↑

Why the Parts Still Matter

Systems thinking is sometimes misunderstood as a rejection of component-level analysis. That is a mistake. Parts matter deeply. A bridge depends on materials, joints, foundations, loads, maintenance, and inspection. A hospital depends on nurses, physicians, equipment, beds, protocols, supply chains, funding, and information systems. An ecosystem depends on species, soils, water, climate, nutrients, and habitat. A model depends on variables, assumptions, data, equations, parameters, and validation.

The systems argument is not that parts are unimportant. It is that parts cannot be fully understood outside the relationships that give them function, consequence, and meaning. A component may perform well in isolation but fail in context. A policy may appear rational on paper but produce harm when implemented through under-resourced institutions. A technology may pass a benchmark but fail in real-world deployment because users, incentives, data quality, maintenance, and governance were misunderstood.

Part-level analysis is especially important when systems fail. A faulty sensor, weak pipe, poorly written rule, missing dataset, undertrained staff role, misaligned metric, or unstable funding stream can produce system-wide consequences. Systems thinking does not excuse poor component design. Instead, it asks how component failure travels through the whole.

Good systems analysis therefore combines decomposition with recomposition. It decomposes the system to understand parts, then recomposes the parts to understand relationships. It asks:

• What are the essential parts of the system?
• What function does each part serve?
• What does each part depend on?
• What depends on each part?
• How does each part behave under stress?
• How does failure in one part affect the whole?
• How does the whole shape the incentives and constraints of each part?

This matters because system-level language can sometimes become a way to ignore detail. A serious analysis of interdependence must still know the parts. It must know the pipes, rules, incentives, species, budgets, contracts, datasets, workflows, communities, sensors, roads, laws, and institutions. Without part-level knowledge, systems thinking becomes decorative. Without system-level knowledge, part-level analysis becomes incomplete.

The discipline lies in moving between levels without losing either one.

Back to top ↑

Interdependence as a Systems Concept

Interdependence means that parts of a system depend on one another for function, stability, meaning, or survival. In an interdependent system, a change in one part can affect other parts directly or indirectly. Interdependence can be material, informational, ecological, institutional, economic, social, technical, or symbolic.

Material interdependence occurs when physical flows connect parts: water, energy, nutrients, goods, waste, money, people, or supplies. Informational interdependence occurs when decisions depend on data, signals, feedback, reporting, interpretation, or communication. Institutional interdependence occurs when organizations rely on laws, funding, standards, enforcement, legitimacy, or coordination. Ecological interdependence occurs when species, habitats, climate, soils, and water cycles shape one another. Social interdependence occurs when people’s wellbeing, identity, opportunity, risk, and agency are affected by relationships with others.

Interdependence is not automatically good. It can create cooperation, resilience, learning, and shared capacity. It can also create fragility, dependence, contagion, lock-in, cascading failure, and unequal vulnerability. A highly connected financial system can move capital efficiently while also transmitting crisis rapidly. A tightly coupled supply chain can reduce cost while weakening redundancy. A centralized platform can improve access while concentrating power. An integrated infrastructure system can improve coordination while increasing the risk of cascading failure.

Systems thinking therefore asks not only whether parts are connected, but how they are connected. Are the connections transparent or hidden? Are they redundant or brittle? Are they reciprocal or exploitative? Are they flexible or locked in? Do they distribute risk fairly? Do they create learning feedback? Do they allow local adaptation? Do they concentrate power?

Interdependence is the structure through which consequences travel.

Back to top ↑

Context, Function, and Meaning

In systems thinking, a part’s meaning depends on context. The same part can have different consequences in different systems. A road can connect communities or divide them. A metric can improve learning or distort behavior. A technology can expand access or deepen surveillance. A rule can protect rights or create exclusion. A reserve fund can strengthen resilience or justify underinvestment. A data system can improve coordination or hide lived experience behind categories.

Function is also contextual. A part may have an official function and an actual system function. Officially, a performance metric may exist to improve quality. In practice, it may pressure workers to prioritize measurable activity over meaningful outcomes. Officially, a complaint system may exist to hear concerns. In practice, it may protect the institution by absorbing grievances without changing structure. Officially, a platform feature may exist to increase connection. In practice, it may increase dependency, extraction, or manipulation.

Part-whole thinking therefore distinguishes among several kinds of function:

• Stated function: what the part is officially said to do.
• Operational function: what the part does in practice.
• System function: how the part contributes to the behavior of the whole.
• Hidden function: what the part enables, protects, obscures, or externalizes.
• Symbolic function: what the part communicates about authority, legitimacy, identity, or value.

For example, a standardized test may have the stated function of measuring learning. Operationally, it may sort students, rank schools, guide funding, shape curriculum, influence teacher behavior, affect family choices, and produce political signals. Its system function may extend far beyond assessment. A systems analysis does not evaluate the test only as an instrument. It evaluates the test as a part embedded in educational, institutional, economic, and political structures.

Context also changes what counts as a good part. A highly efficient component may be harmful if the system needs redundancy. A centralized control system may be powerful in stable conditions but dangerous under disruption. A specialized role may improve performance but reduce flexibility. A just-in-time supply chain may reduce inventory costs but weaken crisis resilience. A predictive model may perform well statistically but fail institutionally if it cannot be explained, contested, audited, or governed.

Systems thinking therefore asks not only “Is this part good?” but “Good for what, under what conditions, at what scale, for whom, and with what consequences for the whole?”

Back to top ↑

Local Optimization and System-Wide Failure

One of the clearest reasons to study wholes and parts together is that optimizing one part can damage the whole. Local optimization occurs when a component, department, metric, process, or actor improves its own performance while weakening system-wide outcomes.

A hospital unit may reduce its own wait time by shifting burdens to another unit. A company may reduce labor costs while increasing turnover, error rates, and knowledge loss. A city may improve vehicle throughput while worsening pedestrian safety, emissions, land use, and public health. A school may raise test scores by narrowing curriculum, increasing stress, or excluding students whose needs are harder to meet. A platform may increase engagement while weakening trust, attention, privacy, and democratic discourse.

Local optimization often occurs because parts are measured separately. A department is rewarded for its own output, not for its effect on downstream capacity. A vendor is paid for delivery, not long-term maintainability. A manager is evaluated on short-term productivity, not burnout or institutional memory. A regulator tracks compliance, not lived outcomes. A technology team optimizes accuracy, not accountability or repair.

This is not an argument against improvement. It is an argument for system-aware improvement. Improving a part is valuable when the improvement strengthens the whole or serves a legitimate system goal. But improvement becomes harmful when it transfers burden, hides cost, creates fragility, or distorts behavior.

Local optimization can produce several system-wide failures:

• Burden shifting: one part improves by moving cost or risk elsewhere.
• Metric distortion: measured performance improves while real outcomes worsen.
• Fragility: efficiency gains remove redundancy and adaptive capacity.
• Coordination failure: parts optimize independently and undermine collective performance.
• Externalization: harms are pushed outside the system boundary.
• Delayed damage: short-term gains accumulate long-term costs.

Systems thinking asks whether a part’s success is compatible with the whole’s health. This is especially important in sustainability, governance, infrastructure, public policy, and organizational design, where narrow optimization can create hidden damage that becomes visible only after delay.

A system is not well governed when every part can claim success while the whole declines.

Back to top ↑

Nested Systems and Levels of Analysis

Systems are often nested. A part at one level can be a whole at another level. A cell is part of an organ, but it is also a system of membranes, organelles, molecules, and regulatory processes. A department is part of an organization, but it is also a system of people, workflows, tools, norms, and goals. A city is part of a region, but it is also a system of neighborhoods, infrastructures, institutions, economies, and ecosystems.

Nested systems require careful levels of analysis. A problem can look different depending on the level at which it is studied. Traffic congestion can be studied at the level of a road segment, neighborhood, metropolitan region, labor market, housing policy, public transit system, or climate strategy. Each level reveals different causes and interventions.

The challenge is not to find the single correct level. The challenge is to understand how levels interact. A policy made at the national level may be implemented locally. A local failure may reflect regional funding. A household decision may be shaped by labor markets and housing systems. A school outcome may reflect classroom practice, district policy, state funding, neighborhood conditions, and national politics.

Nested systems also create cross-scale effects. A local decision can produce regional consequences. A global market shift can reshape local livelihoods. A household burden can reflect national policy. A technical design choice can affect institutional trust. An ecological threshold can disrupt economic systems. A cultural norm can influence organizational behavior.

Systems thinking therefore studies vertical relationships as well as horizontal ones. Horizontal relationships connect parts at the same level. Vertical relationships connect parts and wholes across levels. Together, they reveal how system behavior is generated across scale.

Interdependence is rarely flat. It is layered.

Back to top ↑

Interdependence, Fragility, and Resilience

Interdependence can create strength or fragility. A resilient system uses relationships to absorb disturbance, redistribute stress, learn, adapt, and recover. A fragile system uses relationships in ways that transmit stress, amplify failure, remove alternatives, and produce cascading breakdown.

The difference often depends on the structure of interdependence. Redundant pathways can improve resilience. Hidden dependencies can increase fragility. Modular design can contain failure. Tight coupling can accelerate breakdown. Diversity can support adaptation. Uniformity can improve efficiency while reducing flexibility. Local autonomy can improve response under uncertainty. Centralized control can coordinate action but also create bottlenecks.

Infrastructure systems show this clearly. Electric grids, water systems, transportation networks, communications systems, emergency services, hospitals, and supply chains are deeply interdependent. These relationships can support modern life, but they also create cascading risks. A power outage can affect water treatment, hospital operations, communications, traffic systems, food storage, and emergency response. The problem is not that the systems are connected. The problem is whether the connections are governed, redundant, visible, and resilient.

Ecological systems also show how interdependence shapes resilience. Biodiversity can stabilize ecosystems by distributing functions across species. Soil health depends on microbial life, water retention, plant roots, nutrient cycles, land management, and climate. Remove enough relationships, and the system may cross a threshold. The collapse may seem sudden, but the fragility may have been accumulating through loss of interdependence.

Resilience should not be confused with the ability to endure harm indefinitely. A system that forces vulnerable people to absorb repeated shocks is not resilient in an ethical sense. It may be exploiting human or ecological reserves. Workers may “adapt” by burning out. Communities may “cope” by absorbing neglect. Ecosystems may appear stable while losing regenerative capacity. True resilience requires attention to who or what is doing the absorbing.

Systems thinking therefore asks whether interdependence distributes support or merely distributes burden. It asks whether the whole protects its parts or consumes them.

Back to top ↑

Power, Dependency, and Unequal Interdependence

Interdependence is often unequal. The language of systems can make relationships sound balanced, but many relationships involve asymmetry. One part may depend on another more than it is depended upon. One actor may set the terms under which others must operate. One institution may externalize risk while another absorbs it. One group may provide essential labor while receiving little authority, protection, or recognition.

Systems thinking must therefore distinguish mutual interdependence from dependency under unequal power. A household may depend on a landlord, employer, school, transit system, healthcare provider, and public agency. Those institutions may affect the household far more than the household can affect them. A small supplier may depend on a dominant buyer. A community may depend on a polluting employer. A user may depend on a digital platform that controls visibility, data, access, and appeal. A worker may depend on scheduling systems, performance metrics, and management decisions they cannot influence.

Unequal interdependence shapes vulnerability. When a powerful part fails, weaker parts may absorb the consequences. When a central platform changes policy, dependent creators, businesses, communities, or workers may lose income or access. When a public agency lacks capacity, residents with fewer alternatives suffer first. When infrastructure fails, communities with less political power may wait longer for repair.

Structural analysis should therefore ask:

• Who depends on whom?
• Who controls the terms of interdependence?
• Who can exit the relationship?
• Who has voice when the system changes?
• Who absorbs risk when the whole is optimized?
• Who benefits from hidden dependency?
• Whose contribution is essential but undervalued?

Power also determines which parts are treated as central and which are treated as peripheral. In many systems, the parts most essential to survival are least visible: care work, maintenance, sanitation, ecological regeneration, frontline labor, local knowledge, administrative coordination, and social trust. Systems thinking can make these hidden dependencies visible.

A whole can be organized around the extraction of value from its parts. It can also be organized around mutual support, legitimate coordination, and shared flourishing. Part-whole analysis is therefore not only technical. It is ethical and political.

Back to top ↑

Back to top ↑

Mathematics, Computation, and Modeling

Part-whole relationships can be studied through qualitative inquiry, diagrams, institutional analysis, ecological observation, organizational research, and stakeholder knowledge. They can also be represented computationally through networks, matrices, dynamic models, simulations, dependency maps, and scenario analysis. The goal is not to make interdependence look technical for its own sake. The goal is to make relationships explicit enough to examine, test, question, and revise.

A simple system can be represented as a set of parts and relationships:

A network model expresses this relationship as nodes and edges:

Interdependence can also be represented through an adjacency matrix:

System behavior can be modeled dynamically when the state of one part affects another over time:

For systems inquiry, these models can support practical questions:

• Which parts are most connected?
• Which parts are most dependent on others?
• Which parts create bottlenecks?
• Which failures might cascade?
• Where does redundancy exist?
• Where is the system tightly coupled?
• Which dependencies are hidden?
• Which interventions strengthen the whole rather than merely improving one part?

Computational modeling should not replace qualitative knowledge. A dependency matrix may show that two parts are connected, but it may not reveal whether the relationship is trusted, exploitative, informal, politically contested, historically unjust, or practically fragile. A network metric may identify centrality, but not legitimacy. A simulation may show cascading failure, but not whose suffering is treated as acceptable. Systems modeling is strongest when it is joined to domain expertise, ethical interpretation, and stakeholder knowledge.

Back to top ↑

Python Workflow: Part-Whole Dependency and Resilience Diagnostics

The Python workflow below turns the article’s part-whole argument into a small reproducible model. It compares four scenarios: local optimization, visible dependencies, resilient coordination, and balanced interdependence. The script uses only the Python standard library, writes CSV outputs relative to the article folder, and is designed as a clear starting point for companion repository work.

# part_whole_interdependence_workflow.py
# Dependency-light workflow for part-whole dependency, local optimization,
# failure propagation, and resilience diagnostics.
# Writes outputs relative to the article root.

from __future__ import annotations

from dataclasses import dataclass
from pathlib import Path
import csv
from statistics import mean

ARTICLE_ROOT = Path(__file__).resolve().parents[1]
TABLES = ARTICLE_ROOT / "outputs" / "tables"


@dataclass
class Scenario:
    name: str
    local_optimization: float
    dependency_visibility: float
    redundancy: float
    modularity: float
    coordination_capacity: float
    feedback_quality: float
    power_balance: float
    stress_exposure: float


def clamp(value: float, low: float = 0.0, high: float = 100.0) -> float:
    return max(low, min(high, value))


def run_scenario(scenario: Scenario, periods: int = 36) -> list[dict[str, object]]:
    whole_system_health = 48.0
    dependency_risk = scenario.stress_exposure * 52.0
    resilience_stock = 32.0 + scenario.redundancy * 18.0
    coordination_memory = scenario.coordination_capacity * 42.0
    rows: list[dict[str, object]] = []

    for period in range(periods + 1):
        local_gain = clamp(
            scenario.local_optimization * 24.0
            + max(0.0, 55.0 - dependency_risk) * 0.10
        )

        visibility_gain = clamp(
            scenario.dependency_visibility * 22.0
            + scenario.feedback_quality * 16.0
            + coordination_memory * 0.08
        )

        burden_shift = clamp(
            scenario.local_optimization * 20.0
            + scenario.stress_exposure * 18.0
            + max(0.0, 55.0 - scenario.power_balance * 100.0) * 0.12
            - visibility_gain * 0.14
        )

        cascade_risk = clamp(
            dependency_risk * 0.42
            + burden_shift * 0.24
            + max(0.0, 55.0 - resilience_stock) * 0.20
            - scenario.modularity * 8.0
        )

        resilience_flow = clamp(
            scenario.redundancy * 4.0
            + scenario.modularity * 3.6
            + scenario.coordination_capacity * 3.2
            + scenario.feedback_quality * 2.8
            - cascade_risk * 0.05
        )

        resilience_stock = clamp(
            resilience_stock
            + resilience_flow * 0.32
            + scenario.power_balance * 1.4
            - burden_shift * 0.08
        )

        dependency_risk = clamp(
            dependency_risk
            + burden_shift * 0.18
            + scenario.stress_exposure * 1.2
            - visibility_gain * 0.12
            - resilience_stock * 0.06
        )

        coordination_memory = clamp(
            coordination_memory
            + scenario.coordination_capacity * 1.8
            + scenario.feedback_quality * 1.6
            + visibility_gain * 0.05
            - cascade_risk * 0.04
        )

        whole_system_health = clamp(
            whole_system_health
            + resilience_stock * 0.08
            + coordination_memory * 0.06
            + visibility_gain * 0.06
            - dependency_risk * 0.10
            - cascade_risk * 0.08
            - max(0.0, local_gain - 18.0) * 0.04
        )

        interdependence_score = clamp(
            whole_system_health * 0.30
            + resilience_stock * 0.24
            + coordination_memory * 0.18
            + visibility_gain * 0.16
            - dependency_risk * 0.14
            - cascade_risk * 0.10
        )

        rows.append({
            "period": period,
            "scenario": scenario.name,
            "local_gain": round(local_gain, 3),
            "visibility_gain": round(visibility_gain, 3),
            "burden_shift": round(burden_shift, 3),
            "cascade_risk": round(cascade_risk, 3),
            "dependency_risk": round(dependency_risk, 3),
            "resilience_stock": round(resilience_stock, 3),
            "coordination_memory": round(coordination_memory, 3),
            "whole_system_health": round(whole_system_health, 3),
            "interdependence_score": round(interdependence_score, 3),
        })

    return rows


def write_csv(path: Path, rows: list[dict[str, object]]) -> None:
    path.parent.mkdir(parents=True, exist_ok=True)
    if not rows:
        raise ValueError(f"No rows to write: {path}")
    with path.open("w", newline="", encoding="utf-8") as handle:
        writer = csv.DictWriter(handle, fieldnames=list(rows[0].keys()))
        writer.writeheader()
        writer.writerows(rows)


def summarize(rows: list[dict[str, object]]) -> list[dict[str, object]]:
    output: list[dict[str, object]] = []
    for scenario_name in sorted({row["scenario"] for row in rows}):
        subset = [row for row in rows if row["scenario"] == scenario_name]
        final = subset[-1]
        avg_cascade = mean(float(row["cascade_risk"]) for row in subset)
        avg_resilience = mean(float(row["resilience_stock"]) for row in subset)
        avg_score = mean(float(row["interdependence_score"]) for row in subset)

        if float(final["interdependence_score"]) >= 65 and float(final["cascade_risk"]) <= 35:
            diagnostic = "healthy interdependence with resilient whole-system behavior"
        elif avg_cascade >= 55:
            diagnostic = "interdependence is transmitting fragility and cascade risk"
        elif avg_resilience >= 55:
            diagnostic = "partial resilience with remaining dependency risk"
        else:
            diagnostic = "local optimization or hidden dependency weakens the whole"

        output.append({
            "scenario": scenario_name,
            "final_interdependence_score": final["interdependence_score"],
            "final_whole_system_health": final["whole_system_health"],
            "final_dependency_risk": final["dependency_risk"],
            "final_cascade_risk": final["cascade_risk"],
            "final_resilience_stock": final["resilience_stock"],
            "average_cascade_risk": round(avg_cascade, 3),
            "average_resilience_stock": round(avg_resilience, 3),
            "average_interdependence_score": round(avg_score, 3),
            "diagnostic": diagnostic,
        })

    return output


def main() -> None:
    scenarios = [
        Scenario("Local optimization", 0.82, 0.24, 0.22, 0.24, 0.28, 0.26, 0.24, 0.72),
        Scenario("Visible dependencies", 0.58, 0.66, 0.38, 0.42, 0.48, 0.56, 0.42, 0.58),
        Scenario("Resilient coordination", 0.44, 0.72, 0.70, 0.68, 0.72, 0.70, 0.62, 0.42),
        Scenario("Balanced interdependence", 0.34, 0.84, 0.82, 0.78, 0.80, 0.82, 0.76, 0.30),
    ]

    rows: list[dict[str, object]] = []
    for scenario in scenarios:
        rows.extend(run_scenario(scenario))

    write_csv(TABLES / "part_whole_interdependence_timeseries.csv", rows)
    write_csv(TABLES / "part_whole_interdependence_summary.csv", summarize(rows))

    print("Part-whole interdependence workflow complete.")
    print(TABLES / "part_whole_interdependence_timeseries.csv")


if __name__ == "__main__":
    main()

The workflow is intentionally simple enough to inspect. It shows how local optimization can generate short-term gains while increasing burden shifting, dependency risk, and cascade risk. Stronger dependency visibility, redundancy, modularity, coordination, feedback, and power balance improve whole-system health and interdependence over time. The model is synthetic and illustrative; it supports disciplined inquiry rather than replacing domain expertise, stakeholder evidence, or affected-community knowledge.

Back to top ↑

R Workflow: Interdependence Summary and Visualization

The R workflow reads the Python-generated time-series output, creates scenario summaries, and exports base R plots for whole-system health, dependency risk, cascade risk, resilience stock, and interdependence score. It uses only base R so it remains portable across simple local environments.

# part_whole_interdependence_diagnostics.R
# Base R workflow for interdependence summary and visualization.

args <- commandArgs(trailingOnly = FALSE)
file_arg <- grep("^--file=", args, value = TRUE)

if (length(file_arg) > 0) {
  script_path <- normalizePath(sub("^--file=", "", file_arg[1]), mustWork = TRUE)
  article_root <- normalizePath(file.path(dirname(script_path), ".."), mustWork = TRUE)
} else {
  article_root <- getwd()
}

setwd(article_root)

tables_dir <- file.path(article_root, "outputs", "tables")
figures_dir <- file.path(article_root, "outputs", "figures")

if (!dir.exists(tables_dir)) {
  dir.create(tables_dir, recursive = TRUE)
}

if (!dir.exists(figures_dir)) {
  dir.create(figures_dir, recursive = TRUE)
}

timeseries_path <- file.path(tables_dir, "part_whole_interdependence_timeseries.csv")

if (!file.exists(timeseries_path)) {
  stop(paste("Missing", timeseries_path, "Run the Python workflow first."))
}

data <- read.csv(timeseries_path, stringsAsFactors = FALSE)

last_by_scenario <- do.call(
  rbind,
  lapply(split(data, data$scenario), function(df) df[nrow(df), ])
)

avg_cascade <- aggregate(cascade_risk ~ scenario, data = data, FUN = mean)
avg_resilience <- aggregate(resilience_stock ~ scenario, data = data, FUN = mean)
avg_score <- aggregate(interdependence_score ~ scenario, data = data, FUN = mean)

names(avg_cascade)[2] <- "average_cascade_risk"
names(avg_resilience)[2] <- "average_resilience_stock"
names(avg_score)[2] <- "average_interdependence_score"

final_fields <- last_by_scenario[, c(
  "scenario",
  "interdependence_score",
  "whole_system_health",
  "dependency_risk",
  "cascade_risk",
  "resilience_stock"
)]

names(final_fields) <- c(
  "scenario",
  "final_interdependence_score",
  "final_whole_system_health",
  "final_dependency_risk",
  "final_cascade_risk",
  "final_resilience_stock"
)

summary_table <- Reduce(
  function(x, y) merge(x, y, by = "scenario"),
  list(avg_cascade, avg_resilience, avg_score, final_fields)
)

summary_table$diagnostic <- ifelse(
  summary_table$final_interdependence_score >= 65 &
    summary_table$final_cascade_risk <= 35,
  "healthy interdependence with resilient whole-system behavior",
  ifelse(
    summary_table$average_cascade_risk >= 55,
    "interdependence is transmitting fragility and cascade risk",
    ifelse(
      summary_table$average_resilience_stock >= 55,
      "partial resilience with remaining dependency risk",
      "local optimization or hidden dependency weakens the whole"
    )
  )
)

write.csv(
  summary_table,
  file.path(tables_dir, "part_whole_interdependence_r_summary.csv"),
  row.names = FALSE
)

plot_metric <- function(metric, label, file_name) {
  png(file.path(figures_dir, file_name), width = 1200, height = 700)
  scenarios <- unique(data$scenario)
  plot(
    NA,
    xlim = range(data$period),
    ylim = range(data[[metric]], na.rm = TRUE),
    xlab = "Period",
    ylab = label,
    main = paste(label, "by Scenario")
  )
  for (scenario_name in scenarios) {
    subset_data <- data[data$scenario == scenario_name, ]
    lines(subset_data$period, subset_data[[metric]], lwd = 2)
  }
  legend("topleft", legend = scenarios, lwd = 2, cex = 0.8, bty = "n")
  grid()
  dev.off()
}

plot_metric("whole_system_health", "Whole-system health", "whole_system_health_trajectories.png")
plot_metric("dependency_risk", "Dependency risk", "dependency_risk_trajectories.png")
plot_metric("cascade_risk", "Cascade risk", "cascade_risk_trajectories.png")
plot_metric("resilience_stock", "Resilience stock", "resilience_stock_trajectories.png")
plot_metric("interdependence_score", "Interdependence score", "interdependence_score_trajectories.png")

print(summary_table)

This workflow supports the article’s central methodological claim: the performance of a part must be interpreted through its relationships with the whole. The R outputs help readers see whether interdependence is distributing support or transmitting fragility.

Back to top ↑

GitHub Repository

The companion repository for this article should help readers represent parts, wholes, dependencies, interdependence, failure propagation, local optimization, and resilience using synthetic datasets and reproducible examples. The repository should support both conceptual learning and computational experimentation while preserving clear documentation about assumptions, limits, and responsible use.

articles/wholes-parts-and-interdependence/
├── python/
│   ├── part_whole_interdependence_workflow.py
│   ├── dependency_matrix_analysis.py
│   ├── part_whole_network_model.py
│   ├── local_optimization_scenario.py
│   ├── failure_propagation_simulation.py
│   ├── interdependence_resilience_diagnostics.py
│   ├── stock_flow_interdependence.py
│   ├── validation_checks.py
│   └── run_all_part_whole_workflows.py
├── r/
│   ├── part_whole_interdependence_diagnostics.R
│   ├── dependency_visualization.R
│   ├── part_whole_summary_tables.R
│   ├── local_optimization_comparison.R
│   ├── interdependence_scenario_plots.R
│   ├── resilience_indicator_visualization.R
│   └── run_all_part_whole_workflows.R
├── julia/
│   ├── dynamic_interdependence_examples.jl
│   └── nonlinear_part_whole_feedback.jl
├── sql/
│   ├── schema_system_parts.sql
│   ├── schema_dependency_relationships.sql
│   ├── schema_part_whole_levels.sql
│   ├── schema_scenarios.sql
│   ├── schema_indicators.sql
│   └── schema_model_runs.sql
├── rust/
│   └── interdependence_diagnostics_cli.rs
├── go/
│   └── dependency_pathway_utility.go
├── cpp/
│   ├── efficient_dependency_network.cpp
│   └── failure_propagation_example.cpp
├── fortran/
│   └── recurrence_interdependence_model.f90
├── c/
│   └── low_level_dependency_simulation.c
├── docs/
│   ├── modeling_principles.md
│   ├── article_notes.md
│   ├── assumptions_and_limitations.md
│   └── responsible_use.md
├── data/
│   ├── synthetic_system_parts.csv
│   ├── synthetic_dependency_edges.csv
│   ├── synthetic_part_whole_levels.csv
│   ├── synthetic_scenarios.csv
│   └── synthetic_indicators.csv
├── outputs/
│   ├── figures/
│   └── tables/
└── notebooks/
    ├── python_part_whole_walkthrough.ipynb
    └── r_interdependence_visualization_placeholder.ipynb

This repository structure supports the central argument of the article. The data/ folder separates parts, dependencies, nested levels, scenarios, and indicators. The python/ and r/ folders support dependency analysis, visualization, local optimization, failure propagation, and resilience diagnostics. The julia/ folder supports dynamic and nonlinear interdependence examples. The sql/ folder defines database schemas for system parts, relationships, nested levels, scenarios, indicators, and model runs. The lower-level language folders provide efficient examples for diagnostics, dependency paths, recurrence, and simulation.

Back to top ↑

Back to top ↑

Back to top ↑

Why Part-Whole Thinking Matters

Wholes, parts, and interdependence are not abstract philosophical concerns. They shape how societies govern infrastructure, design organizations, manage ecosystems, build technologies, deliver public services, respond to crises, and understand responsibility. If parts are studied without wholes, analysis becomes fragmented. If wholes are discussed without parts, analysis becomes vague. Systems thinking requires disciplined movement between both.

Part-whole thinking teaches that local outcomes often reflect larger arrangements. It shows why a component can fail because of system conditions, why a system can decline despite competent parts, why local optimization can create collective damage, and why resilience depends on the quality of relationships. It also reveals hidden dependencies: the workers, ecosystems, infrastructures, institutions, and forms of care that make visible systems possible.

This way of thinking is especially important in an age of tightly coupled technological, ecological, economic, and institutional systems. Climate disruption, infrastructure fragility, public-health vulnerability, organizational burnout, AI governance, supply-chain risk, inequality, and institutional distrust are not isolated component problems. They are part-whole problems. They require analysis that can see both the concrete part and the wider system that gives it meaning.

Systems thinking begins when the part is no longer isolated from the whole, and the whole is no longer imagined apart from its parts.

Back to top ↑

Related Articles

• What Is Systems Thinking?
• Patterns, Events, and Structural Explanation
• System Boundaries and Problem Framing
• Causality in Systems Thinking
• Systems Thinking and Levels of Analysis
• Feedback Loops and System Behavior
• Behavior Over Time and Structural Explanation
• Dynamic Complexity and Policy Resistance

Further Reading

• Meadows, Donella H. Thinking in Systems: A Primer. Chelsea Green Publishing.
• Bertalanffy, Ludwig von. General System Theory: Foundations, Development, Applications. George Braziller.
• Checkland, Peter. Systems Thinking, Systems Practice. John Wiley & Sons.
• Senge, Peter M. The Fifth Discipline: The Art and Practice of the Learning Organization. Doubleday/Currency.
• Sterman, John D. Business Dynamics: Systems Thinking and Modeling for a Complex World. Irwin/McGraw-Hill.
• Holland, John H. Hidden Order: How Adaptation Builds Complexity. Addison-Wesley.
• Capra, Fritjof and Luisi, Pier Luigi. The Systems View of Life: A Unifying Vision. Cambridge University Press.

Back to top ↑

References

• Bertalanffy, L. von (1968) General System Theory: Foundations, Development, Applications. New York: George Braziller.
• Capra, F. and Luisi, P.L. (2014) The Systems View of Life: A Unifying Vision. Cambridge: Cambridge University Press.
• Checkland, P. (1981) Systems Thinking, Systems Practice. Chichester: John Wiley & Sons.
• Forrester, J.W. (1961) Industrial Dynamics. Cambridge, MA: MIT Press.
• Holland, J.H. (1995) Hidden Order: How Adaptation Builds Complexity. Reading, MA: Addison-Wesley.
• Meadows, D.H. (2008) Thinking in Systems: A Primer. White River Junction, VT: Chelsea Green Publishing. Available at: https://www.chelseagreen.com/product/thinking-in-systems/
• Senge, P.M. (1990) The Fifth Discipline: The Art and Practice of the Learning Organization. New York: Doubleday/Currency.
• Sterman, J.D. (2000) Business Dynamics: Systems Thinking and Modeling for a Complex World. Boston: Irwin/McGraw-Hill.

Back to top ↑