Fixes That Fail

Last Updated June 1, 2026

Fixes that fail is one of the most useful system archetypes because it describes a pattern that appears everywhere: a quick solution reduces a visible symptom, but creates delayed consequences that make the original problem return, deepen, or spread. The fix works just enough to become attractive. It relieves pressure. It buys time. It reassures leaders, stakeholders, voters, customers, managers, or the public that something is being done. But because the deeper structure remains unchanged, the system eventually pushes back.

The danger of a fix that fails is not that the initial fix is always irrational. Many quick fixes are understandable, necessary, or even humane in the short term. Emergency repair, overtime, temporary staffing, debt, subsidies, enforcement, crisis communication, technical patches, and rapid response can all be needed. The failure begins when temporary relief becomes a substitute for structural repair. The system treats the symptom, misses the cause, and then becomes dependent on the same fix that is quietly making the problem harder to solve.

This article examines fixes that fail as a core systems archetype. It explains the difference between symptom relief and structural repair, shows why delayed consequences make failed fixes hard to recognize, and examines how institutions become trapped in repeated quick-response cycles. It also explores the ethical stakes of short-term fixes: who receives relief, who absorbs the delayed cost, what harm is externalized, and why temporary solutions must be connected to deeper repair if they are not to reproduce the very problems they were meant to solve.

Why Fixes That Fail Matters

Fixes that fail matters because systems often reward short-term relief more than long-term repair. A visible problem creates pressure. People demand action. Leaders need to show response. Institutions reach for the fastest available tool. The symptom improves. The pressure falls. The fix is judged successful. But later, the problem returns, often with additional complications.

This pattern is common because the short-term effect is usually easier to see than the delayed consequence. Overtime reduces backlog this week, while fatigue and turnover appear months later. Deferred maintenance saves money this budget cycle, while infrastructure failure appears years later. A digital workaround reduces processing time, while appeal burden and hidden exclusion appear later. Emergency aid reduces immediate distress, while the underlying housing, health, income, or care system remains unrepaired.

The archetype helps systems thinkers ask a different question. Instead of asking only whether the fix reduced the symptom, it asks what the fix did to the system. Did it deplete capacity? Did it increase dependence? Did it hide the need for deeper repair? Did it shift cost to workers, applicants, communities, ecosystems, or future budgets? Did it make the original problem harder to solve?

Fixes that fail is not an argument against emergency response. It is an argument against mistaking emergency response for systems change. The quick fix may be necessary, but it must be connected to fundamental repair. Otherwise the system learns the wrong lesson: that temporary pressure relief is enough.

Back to top ↑

What the Fixes-That-Fail Archetype Means

The fixes-that-fail archetype contains two linked feedback loops. The first is a balancing loop: the system experiences a problem symptom and applies a fix that reduces the symptom. This loop creates relief. The second is a delayed reinforcing or worsening loop: the fix produces an unintended consequence that increases the original problem or creates a new related problem. Because the consequence is delayed, the connection is easy to miss.

The basic structure is simple:

The failure is not always immediate. That is what makes the archetype so seductive. If the negative consequence appeared instantly, the fix would be easier to reject. Instead, the fix works first. It reduces pressure. It creates a success story. It may even be institutionalized as best practice. Only later does the hidden cost appear.

The archetype often follows this sequence:

• A visible symptom creates pressure for action.
• A quick fix is chosen because it is available, familiar, or politically acceptable.
• The symptom improves in the short term.
• The system interprets the improvement as evidence that the fix works.
• The fix creates delayed side effects.
• The side effects recreate or worsen the original symptom.
• The system applies the same fix again because it worked before.
• The deeper problem becomes harder to solve.

Fixes that fail are especially common when institutions are judged on short evaluation windows. If success is measured quarterly, annually, or within a political cycle, delayed consequences may not count. The system rewards visible response while externalizing long-term cost.

Systems thinking stretches the time horizon. It asks what happens after the fix appears to work.

Back to top ↑

Symptom Relief versus Structural Repair

The central distinction in this archetype is between symptom relief and structural repair. Symptom relief reduces the visible pressure. Structural repair changes the conditions that generate the symptom. Both may be needed, but they are not the same.

Symptom relief is usually faster. It may require fewer changes to rules, incentives, budgets, authority, or institutional identity. It can be implemented through existing routines. It is easier to communicate because it addresses the visible problem directly. Structural repair is slower and harder. It requires diagnosing the system, changing flows, rebuilding stocks, redesigning feedback, reducing delays, altering rules, and often confronting power.

For example, a public agency facing long wait times may respond by pushing staff to process cases faster. That is symptom relief. Structural repair might involve simplifying eligibility rules, reducing documentation burden, increasing staffing, improving language access, redesigning technology, strengthening appeal systems, and measuring administrative burden. The first reduces visible delay for a time. The second changes the system that produces delay.

Symptom relief becomes dangerous when it is counted as repair. A temporary staffing surge is not the same as sustainable capacity. A communication campaign is not the same as trust repair. A road expansion is not the same as mobility redesign. A patch is not the same as maintenance renewal. A subsidy is not the same as structural affordability. A safety rule is not the same as a culture of safety.

Fixes that fail teach that relief should be used honestly. It should buy time for repair, not replace repair.

Back to top ↑

The Quick-Fix Loop

The quick-fix loop is a balancing loop. A problem symptom rises. The system responds. The response reduces the symptom. The loop is balancing because it pushes the system back toward a desired condition. In isolation, this loop looks helpful.

Consider a service backlog. The backlog rises. Managers authorize overtime. Staff process more cases. The backlog falls. From a narrow view, the fix worked. Consider congestion. Travel delays rise. Road capacity is expanded. Travel times improve temporarily. From a narrow view, the fix worked. Consider public distrust. Criticism rises. Leaders launch a messaging campaign. Criticism softens briefly. From a narrow view, the fix worked.

The quick-fix loop becomes attractive for several reasons:

• It addresses the visible symptom directly.
• It often uses resources already available.
• It produces results within the evaluation window.
• It reassures stakeholders that action is being taken.
• It avoids deeper conflict over structure, rules, power, or investment.
• It can be repeated without redesigning the system.

The quick fix may be humane in the moment. If people are waiting for benefits, emergency processing matters. If a bridge is unsafe, emergency repair matters. If patients need care, surge staffing matters. If households face crisis, immediate assistance matters. The problem is not relief itself. The problem is relief without repair.

A system trapped in the quick-fix loop often develops institutional habits. It builds procedures for crisis response but not prevention. It funds emergency repair but not maintenance. It rewards heroics but not capacity planning. It praises responsiveness but ignores the conditions that keep producing emergencies.

The quick-fix loop should therefore be treated as a bridge. It can stabilize the system long enough to address root structure. If it becomes the strategy, it becomes part of the problem.

Back to top ↑

The Delayed Consequence Loop

The delayed consequence loop is the hidden part of the archetype. The quick fix produces a side effect that appears later. That side effect increases the original problem, weakens capacity, creates dependency, shifts burden, or produces a new problem that feeds back into the original symptom.

In workforce systems, overtime reduces backlog but increases fatigue. Fatigue increases errors. Errors increase rework. Rework increases workload. Workload increases burnout and turnover. Turnover reduces capacity. Reduced capacity increases backlog. The quick fix has become a generator of the original problem.

In infrastructure systems, deferred maintenance saves money now. But asset condition declines. Failure risk rises. Emergency repairs become more frequent. Emergency repair is more expensive than planned maintenance. More budget is consumed by crisis response. Preventive maintenance is crowded out further. The fix deepens the maintenance trap.

The delay is critical. If the unintended consequence appeared immediately, the system would learn quickly. But delayed harm often arrives after the budget cycle, leadership change, election, quarterly report, grant period, crisis window, or performance review. The people credited with the fix may not be the people who manage the consequence.

Common delayed consequences include:

• capacity depletion;
• turnover and loss of institutional memory;
• maintenance backlog;
• trust erosion;
• appeal volume and rework;
• debt burden;
• increased demand;
• ecological degradation;
• administrative burden;
• reduced learning capacity;
• dependence on the fix itself.

The delayed consequence loop reveals why systems can appear rational at each step while becoming irrational over time. Each fix makes sense locally. The pattern fails structurally.

Back to top ↑

Why the Pattern Is Hard to See

Fixes that fail are difficult to see because the system separates the fix from its consequences. The fix is visible, immediate, and measurable. The consequence is delayed, distributed, and often experienced by different people. The institution may not connect the two.

Several features make the pattern hard to diagnose. First, the quick fix often produces real improvement. This makes criticism of the fix seem unfair. Second, the delayed consequence may appear through another department, budget, population, or time period. Third, the system may not measure the stock being depleted. Fourth, leaders may be rewarded for immediate response and insulated from later effects. Fifth, people harmed by the delayed consequence may have less power to define the problem.

The pattern is also hard to see because people often frame the repeated problem as evidence that more of the fix is needed. If backlog returns, the system demands more overtime. If congestion returns, it demands more lanes. If distrust returns, it demands more communication. If debt pressure returns, it demands more borrowing. The recurrence is interpreted as insufficient intensity, not structural failure.

Systems thinking breaks this interpretation by asking whether the fix is feeding the problem. If each application of the fix makes the future problem more likely, the system is trapped.

Back to top ↑

Dependency, Repetition, and Institutional Habit

Fixes that fail can become institutional habits. The organization learns how to perform the fix. It creates procedures, roles, budgets, vendors, dashboards, crisis teams, exception processes, or political narratives around it. The fix becomes normalized. Over time, the system becomes less capable of pursuing the fundamental solution.

This is where fixes that fail begins to overlap with shifting the burden. The quick fix not only produces delayed consequences; it can displace the deeper solution. Overtime displaces staffing and workload redesign. Emergency repair displaces maintenance planning. Policing displaces housing, care, and prevention. Debt displaces income security. Messaging displaces trust repair. Automation displaces process simplification and human accountability.

Dependency appears when the system cannot imagine functioning without the fix. The phrase “this is just how we handle it” is often a warning sign. Crisis response becomes operating model. Exceptional measures become normal. Short-term patches become infrastructure. The system adapts around the fix rather than repairing the condition that makes the fix necessary.

Signs of dependency include:

• the fix is used more frequently over time;
• the underlying problem returns faster after each fix;
• staff or institutions plan around crisis response;
• funding favors emergency action over prevention;
• root-cause proposals are delayed as unrealistic;
• the system loses capacity for fundamental repair;
• people harmed by the fix are treated as outside the problem frame.

Breaking dependency requires transition design. A system cannot always stop a quick fix abruptly without causing harm. It may need to maintain relief while building the fundamental solution. The goal is not moral purity. The goal is structural escape.

Back to top ↑

When Quick Fixes Are Necessary

Not all quick fixes should be rejected. Systems thinking is not a refusal of urgency. If people are harmed now, immediate relief matters. If a bridge is unsafe, emergency repair matters. If households face eviction, emergency assistance matters. If patients need care, surge capacity matters. If a system is failing, stabilization may be necessary before deeper redesign is possible.

The distinction is whether the quick fix is used as a bridge to structural repair or as a replacement for it. A quick fix can be responsible when it is paired with root-cause analysis, time-limited use, monitoring of side effects, transition funding, and accountability for deeper change. It becomes irresponsible when it hides the problem, depletes capacity, shifts burden, or delays repair indefinitely.

Emergency response and prevention should not be treated as opposites. A humane system often needs both. The mistake is funding emergency response while starving prevention, praising heroics while ignoring capacity, or using the urgency of the symptom to avoid the politics of structural repair.

A quick fix should answer four questions before it is used:

• What immediate harm does this fix reduce?
• What delayed consequences could it create?
• What fundamental solution must accompany it?
• How will we know when the fix is no longer needed?

When quick fixes are necessary, systems thinking makes them honest. It refuses to let relief masquerade as transformation.

Back to top ↑

Breaking the Pattern: Pairing Relief with Repair

Breaking a fixes-that-fail pattern requires more than stopping the fix. In many systems, abrupt withdrawal of the fix can produce immediate harm. The better approach is to pair relief with repair: keep people safe now while changing the structure that produces the symptom.

The first step is to name the symptom and the fix. What problem appears? What action reduces it? The second step is to identify the delayed consequence. What stock is depleted? What burden is shifted? What dependency grows? The third step is to identify the fundamental solution. What structural change would reduce the need for the fix?

For backlog, the fundamental solution may include simplifying rules, improving staffing, reducing rework, redesigning technology, increasing trust, and reducing demand drivers. For congestion, it may include land-use reform, transit, pricing, walkability, and reducing car dependency. For maintenance crises, it may include asset management, preventive funding, lifecycle budgeting, and climate adaptation. For public distrust, it may include accountability, participation, reliable service, and burden reduction.

Breaking the pattern also requires new feedback. The system must measure the side effects of the fix, not only the symptom relief. If overtime is used, measure fatigue, errors, turnover, and rework. If emergency repair is used, measure maintenance backlog and asset condition. If automation is used, measure appeals, exclusion, error correction, and user burden. If messaging is used, measure trust, service reliability, and behavior change.

A repair-oriented response should include:

• clear identification of the symptom;
• documentation of the quick fix;
• monitoring of delayed consequences;
• investment in the fundamental solution;
• transition criteria for reducing reliance on the fix;
• expanded system boundaries to include shifted costs;
• participation from people affected by the symptom and the fix;
• accountability for long-term outcomes.

The goal is not to condemn the fix. The goal is to prevent the fix from becoming the system’s way of avoiding repair.

Back to top ↑

Ethics: Who Pays for the Failed Fix?

Fixes that fail have ethical stakes because the benefits of the fix and the costs of failure are often distributed unequally. The institution may receive credit for visible response while workers, applicants, patients, residents, ecosystems, or future generations absorb the delayed harm.

Overtime may help an organization meet targets, but workers absorb fatigue and families absorb lost time. Deferred maintenance may protect a budget, but future residents absorb infrastructure risk. Strict verification may reduce official error, but eligible people absorb burden, delay, and exclusion. Road expansion may reduce congestion briefly, but communities absorb pollution, sprawl, and long-term dependence. Automation may reduce agency workload, but users absorb appeal labor and error correction.

Ethical analysis asks who experiences the delayed consequence. If the harmed group is outside the official boundary, the fix may look successful from inside the institution. A public agency may count lower internal workload while households face greater burden. A company may count lower labor cost while workers face instability. A city may count development revenue while displaced residents lose community. A platform may count engagement while public trust declines.

Ethical fixes-that-fail analysis asks:

• Who receives immediate relief?
• Who receives institutional credit?
• Who absorbs delayed harm?
• What stock is depleted?
• What cost is externalized?
• Who can contest the fix?
• What repair is owed if the fix causes harm?
• What would the system look like if affected people defined success?

This archetype also challenges blame. When a quick fix fails, institutions may blame the people affected by the delayed consequence: workers are burned out because they lack resilience; applicants are excluded because they failed to comply; residents are congested because they drive too much; communities distrust institutions because they are misinformed. Systems thinking asks what structure created the behavior and who designed or preserved that structure.

The ethical lesson is clear: a fix that fails is not merely inefficient. It may be a way of shifting harm while preserving the appearance of action.

Back to top ↑

Back to top ↑

Mathematics, Computation, and Modeling

Fixes that fail can be represented with simple dynamic models, causal-loop diagrams, stock-flow simulations, delay equations, scenario comparisons, and sensitivity analysis. The purpose of modeling is not to prove that every quick fix fails. It is to clarify when short-term relief produces delayed consequences that undermine the original goal.

A simple symptom-fix model can be written as:

A fixes-that-fail model adds the delayed consequence:

If the fix depletes capacity, the capacity stock can be modeled as:

If problem pressure depends on capacity, the model can be extended:

A responsible intervention model includes both relief and repair:

A dependency indicator can be represented conceptually as:

Modeling fixes that fail should always include the time horizon. A model that stops when the symptom improves will declare success too early. The central question is what happens after the system has had time to respond.

Back to top ↑

Python Workflow: Quick Fixes, Delayed Consequences, Capacity Depletion, and Repair Diagnostics

The Python workflow below turns the fixes-that-fail archetype into a small reproducible systems model. It compares four scenarios: quick fix only, repeated crisis response, relief paired with repair, and transition to structural repair. It also includes one-at-a-time sensitivity analysis for the structural repair scenario. 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.

# fixes_that_fail_workflow.py
# Dependency-light workflow for fixes-that-fail diagnostics:
# quick-fix relief, delayed consequences, capacity depletion,
# dependency ratio, repair investment, and distributional harm.
# Writes outputs relative to the article root.

from __future__ import annotations

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

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


@dataclass
class FixScenario:
    name: str
    initial_problem: float
    demand_pressure: float
    quick_fix_intensity: float
    fix_effectiveness: float
    side_effect_strength: float
    delay_strength: float
    repair_investment: float
    capacity_recovery: float
    burden_reduction: float
    accountability: float
    distributional_safeguard: float
    learning_feedback: float


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


def run_scenario(scenario: FixScenario, periods: int = 64) -> list[dict[str, object]]:
    problem = scenario.initial_problem
    capacity = 58.0 + scenario.capacity_recovery * 18.0
    trust = 44.0 + scenario.accountability * 20.0
    hidden_burden = 40.0 + scenario.quick_fix_intensity * 18.0
    delayed_consequence_stock = 18.0 + scenario.side_effect_strength * 16.0
    repair_stock = 28.0 + scenario.repair_investment * 20.0
    vulnerable_group_harm = 32.0 + scenario.side_effect_strength * 14.0
    fix_history: list[float] = [0.0]
    rows: list[dict[str, object]] = []

    delay_steps = max(0, int(round(scenario.delay_strength * 10.0)))

    for period in range(periods + 1):
        delayed_index = max(0, len(fix_history) - 1 - delay_steps)
        delayed_fix = fix_history[delayed_index]

        system_pressure = clamp(
            scenario.demand_pressure * 18.0
            + max(0.0, problem - 48.0) * 0.22
            + max(0.0, 55.0 - capacity) * 0.16
            + hidden_burden * 0.08
            - scenario.learning_feedback * 4.0,
            0.0,
            120.0,
        )

        quick_fix = clamp(
            scenario.quick_fix_intensity * 18.0
            + system_pressure * 0.22
            - scenario.accountability * 2.0
            - repair_stock * 0.035,
            0.0,
            120.0,
        )

        symptom_relief = clamp(
            quick_fix * scenario.fix_effectiveness * 0.85
            + scenario.accountability * 2.0,
            0.0,
            120.0,
        )

        delayed_consequence = clamp(
            delayed_fix * scenario.side_effect_strength * 0.75
            + scenario.delay_strength * 8.0
            + max(0.0, quick_fix - repair_stock) * 0.08
            - scenario.accountability * 2.5
            - scenario.distributional_safeguard * 2.0,
            0.0,
            120.0,
        )

        repair_flow = clamp(
            scenario.repair_investment * 18.0
            + scenario.capacity_recovery * 12.0
            + scenario.burden_reduction * 11.0
            + scenario.learning_feedback * 8.0
            + scenario.accountability * 7.0,
            0.0,
            120.0,
        )

        capacity_depletion = clamp(
            quick_fix * 0.12
            + hidden_burden * 0.06
            + delayed_consequence_stock * 0.05
            - scenario.capacity_recovery * 4.0
            - scenario.repair_investment * 2.0,
            0.0,
            120.0,
        )

        problem = clamp(
            problem
            + scenario.demand_pressure * 2.1
            + delayed_consequence * 0.13
            + max(0.0, 55.0 - capacity) * 0.06
            - symptom_relief * 0.13
            - repair_flow * 0.09,
            0.0,
            140.0,
        )

        capacity = clamp(
            capacity
            + repair_flow * 0.10
            + scenario.capacity_recovery * 1.2
            - capacity_depletion * 0.12
            - max(0.0, problem - 70.0) * 0.04,
            0.0,
            120.0,
        )

        repair_stock = clamp(
            repair_stock
            + repair_flow * 0.11
            + scenario.learning_feedback * 0.8
            - quick_fix * 0.05
            - scenario.demand_pressure * 0.6,
            0.0,
            120.0,
        )

        delayed_consequence_stock = clamp(
            delayed_consequence_stock
            + delayed_consequence * 0.12
            + quick_fix * 0.04
            - repair_flow * 0.06
            - scenario.accountability * 0.7,
            0.0,
            120.0,
        )

        hidden_burden = clamp(
            hidden_burden
            + delayed_consequence * 0.10
            + quick_fix * 0.05
            - scenario.burden_reduction * 1.8
            - scenario.distributional_safeguard * 1.0,
            0.0,
            100.0,
        )

        vulnerable_group_harm = clamp(
            vulnerable_group_harm
            + hidden_burden * 0.05
            + delayed_consequence_stock * 0.05
            + max(0.0, problem - capacity) * 0.04
            - scenario.distributional_safeguard * 1.7
            - scenario.accountability * 0.8,
            0.0,
            100.0,
        )

        trust = clamp(
            trust
            + scenario.accountability * 1.4
            + repair_stock * 0.035
            + scenario.distributional_safeguard * 0.8
            - hidden_burden * 0.035
            - vulnerable_group_harm * 0.035
            - delayed_consequence_stock * 0.025,
            0.0,
            100.0,
        )

        dependency_ratio = quick_fix / max(1.0, repair_stock + capacity)
        failure_risk = clamp(
            problem * 0.18
            + delayed_consequence_stock * 0.18
            + hidden_burden * 0.16
            + vulnerable_group_harm * 0.18
            + dependency_ratio * 50.0
            - capacity * 0.10
            - trust * 0.08
            - repair_stock * 0.08,
            0.0,
            100.0,
        )

        repair_alignment_score = clamp(
            capacity * 0.18
            + repair_stock * 0.20
            + trust * 0.16
            + repair_flow * 0.14
            + scenario.accountability * 10.0
            + scenario.distributional_safeguard * 10.0
            - problem * 0.14
            - delayed_consequence_stock * 0.14
            - vulnerable_group_harm * 0.16
            - failure_risk * 0.12,
            0.0,
            100.0,
        )

        rows.append({
            "period": period,
            "scenario": scenario.name,
            "problem": round(problem, 3),
            "capacity": round(capacity, 3),
            "trust": round(trust, 3),
            "hidden_burden": round(hidden_burden, 3),
            "delayed_consequence_stock": round(delayed_consequence_stock, 3),
            "repair_stock": round(repair_stock, 3),
            "vulnerable_group_harm": round(vulnerable_group_harm, 3),
            "system_pressure": round(system_pressure, 3),
            "quick_fix": round(quick_fix, 3),
            "symptom_relief": round(symptom_relief, 3),
            "delayed_consequence": round(delayed_consequence, 3),
            "repair_flow": round(repair_flow, 3),
            "capacity_depletion": round(capacity_depletion, 3),
            "dependency_ratio": round(dependency_ratio, 4),
            "failure_risk": round(failure_risk, 3),
            "repair_alignment_score": round(repair_alignment_score, 3),
        })

        fix_history.append(quick_fix)

    return 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_quick_fix = mean(float(row["quick_fix"]) for row in subset)
        avg_repair = mean(float(row["repair_flow"]) for row in subset)
        avg_risk = mean(float(row["failure_risk"]) for row in subset)
        avg_harm = mean(float(row["vulnerable_group_harm"]) for row in subset)
        avg_alignment = mean(float(row["repair_alignment_score"]) for row in subset)

        if float(final["repair_alignment_score"]) >= 65 and float(final["failure_risk"]) <= 35:
            diagnostic = "relief is paired with repair and dependency is declining"
        elif avg_quick_fix > avg_repair and avg_risk >= 55:
            diagnostic = "quick-fix dependency is reproducing the problem"
        elif avg_harm >= 55:
            diagnostic = "delayed costs are being shifted to vulnerable groups"
        elif avg_risk >= 55:
            diagnostic = "delayed consequences dominate the system"
        elif avg_alignment >= 55:
            diagnostic = "partial repair with remaining fix-dependency risk"
        else:
            diagnostic = "weak evidence of durable repair"

        output.append({
            "scenario": scenario_name,
            "final_repair_alignment_score": final["repair_alignment_score"],
            "final_failure_risk": final["failure_risk"],
            "final_problem": final["problem"],
            "final_capacity": final["capacity"],
            "final_delayed_consequence_stock": final["delayed_consequence_stock"],
            "final_vulnerable_group_harm": final["vulnerable_group_harm"],
            "average_quick_fix": round(avg_quick_fix, 3),
            "average_repair_flow": round(avg_repair, 3),
            "average_failure_risk": round(avg_risk, 3),
            "average_vulnerable_group_harm": round(avg_harm, 3),
            "average_repair_alignment_score": round(avg_alignment, 3),
            "diagnostic": diagnostic,
        })

    return output


def one_at_a_time(base: FixScenario, delta: float = 0.10) -> list[dict[str, object]]:
    base_score = float(run_scenario(base)[-1]["repair_alignment_score"])
    parameters = [
        "demand_pressure",
        "quick_fix_intensity",
        "fix_effectiveness",
        "side_effect_strength",
        "delay_strength",
        "repair_investment",
        "capacity_recovery",
        "burden_reduction",
        "accountability",
        "distributional_safeguard",
        "learning_feedback",
    ]

    rows: list[dict[str, object]] = []
    for parameter in parameters:
        for direction in (-1, 1):
            current = getattr(base, parameter)
            revised_value = max(0.0, min(1.0, current + direction * delta))
            revised = replace(base, name=f"{base.name} {parameter} {direction * delta:+.2f}", **{parameter: revised_value})
            revised_score = float(run_scenario(revised)[-1]["repair_alignment_score"])
            rows.append({
                "parameter": parameter,
                "delta": direction * delta,
                "base_value": current,
                "revised_value": revised_value,
                "base_final_repair_alignment_score": round(base_score, 3),
                "revised_final_repair_alignment_score": round(revised_score, 3),
                "score_change": round(revised_score - base_score, 3),
                "absolute_score_change": round(abs(revised_score - base_score), 3),
            })

    return sorted(rows, key=lambda row: float(row["absolute_score_change"]), reverse=True)


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 main() -> None:
    scenarios = [
        FixScenario("Quick fix only", 62.0, 0.70, 0.82, 0.76, 0.72, 0.70, 0.18, 0.22, 0.18, 0.22, 0.20, 0.22),
        FixScenario("Repeated crisis response", 60.0, 0.64, 0.68, 0.70, 0.60, 0.62, 0.34, 0.34, 0.30, 0.34, 0.32, 0.34),
        FixScenario("Relief paired with repair", 58.0, 0.52, 0.46, 0.62, 0.38, 0.38, 0.72, 0.68, 0.66, 0.66, 0.64, 0.64),
        FixScenario("Transition to structural repair", 56.0, 0.42, 0.34, 0.56, 0.24, 0.24, 0.84, 0.82, 0.80, 0.82, 0.84, 0.82),
    ]

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

    write_csv(TABLES / "fixes_that_fail_timeseries.csv", rows)
    write_csv(TABLES / "fixes_that_fail_summary.csv", summarize(rows))
    write_csv(TABLES / "fixes_that_fail_sensitivity_analysis.csv", one_at_a_time(scenarios[-1]))

    print("Fixes-that-fail workflow complete.")
    print(TABLES / "fixes_that_fail_timeseries.csv")


if __name__ == "__main__":
    main()

The workflow is intentionally simple enough to inspect. It shows how visible symptom relief, delayed side effects, capacity depletion, hidden burden, vulnerable-group harm, repair investment, and dependency risk interact over time. It also shows why a fix should be evaluated by what happens after the symptom improves. The model is synthetic and illustrative; it supports disciplined inquiry rather than replacing domain expertise, stakeholder evidence, or ethical judgment.

Back to top ↑

R Workflow: Fix-Failure Summary and Relief-versus-Repair Visualization

The R workflow reads the Python-generated time-series and sensitivity outputs, creates scenario summaries, and exports base R plots for the problem symptom, quick fix, repair flow, delayed consequence stock, failure risk, and repair alignment. It uses only base R so it remains portable across simple local environments.

# fixes_that_fail_diagnostics.R
# Base R workflow for fix-failure summary and relief-versus-repair 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, "fixes_that_fail_timeseries.csv")
sensitivity_path <- file.path(tables_dir, "fixes_that_fail_sensitivity_analysis.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_quick_fix <- aggregate(quick_fix ~ scenario, data = data, FUN = mean)
avg_repair <- aggregate(repair_flow ~ scenario, data = data, FUN = mean)
avg_risk <- aggregate(failure_risk ~ scenario, data = data, FUN = mean)
avg_harm <- aggregate(vulnerable_group_harm ~ scenario, data = data, FUN = mean)
avg_alignment <- aggregate(repair_alignment_score ~ scenario, data = data, FUN = mean)

names(avg_quick_fix)[2] <- "average_quick_fix"
names(avg_repair)[2] <- "average_repair_flow"
names(avg_risk)[2] <- "average_failure_risk"
names(avg_harm)[2] <- "average_vulnerable_group_harm"
names(avg_alignment)[2] <- "average_repair_alignment_score"

final_fields <- last_by_scenario[, c(
  "scenario",
  "repair_alignment_score",
  "failure_risk",
  "problem",
  "capacity",
  "delayed_consequence_stock",
  "vulnerable_group_harm"
)]

names(final_fields) <- c(
  "scenario",
  "final_repair_alignment_score",
  "final_failure_risk",
  "final_problem",
  "final_capacity",
  "final_delayed_consequence_stock",
  "final_vulnerable_group_harm"
)

summary_table <- Reduce(
  function(x, y) merge(x, y, by = "scenario"),
  list(avg_quick_fix, avg_repair, avg_risk, avg_harm, avg_alignment, final_fields)
)

summary_table$diagnostic <- ifelse(
  summary_table$final_repair_alignment_score >= 65 &
    summary_table$final_failure_risk <= 35,
  "relief is paired with repair and dependency is declining",
  ifelse(
    summary_table$average_quick_fix > summary_table$average_repair_flow &
      summary_table$average_failure_risk >= 55,
    "quick-fix dependency is reproducing the problem",
    ifelse(
      summary_table$average_vulnerable_group_harm >= 55,
      "delayed costs are being shifted to vulnerable groups",
      ifelse(
        summary_table$average_failure_risk >= 55,
        "delayed consequences dominate the system",
        ifelse(
          summary_table$average_repair_alignment_score >= 55,
          "partial repair with remaining fix-dependency risk",
          "weak evidence of durable repair"
        )
      )
    )
  )
)

summary_table <- summary_table[order(summary_table$final_repair_alignment_score, decreasing = TRUE), ]

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

if (file.exists(sensitivity_path)) {
  sensitivity <- read.csv(sensitivity_path, stringsAsFactors = FALSE)
  sensitivity_ranked <- sensitivity[order(sensitivity$absolute_score_change, decreasing = TRUE), ]
  write.csv(
    sensitivity_ranked,
    file.path(tables_dir, "fixes_that_fail_sensitivity_ranked_r.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 Fixes-that-Fail 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("problem", "Problem symptom", "problem_trajectories.png")
plot_metric("quick_fix", "Quick fix", "quick_fix_trajectories.png")
plot_metric("repair_flow", "Repair flow", "repair_flow_trajectories.png")
plot_metric("delayed_consequence_stock", "Delayed consequence stock", "delayed_consequence_trajectories.png")
plot_metric("failure_risk", "Failure risk", "failure_risk_trajectories.png")
plot_metric("repair_alignment_score", "Repair alignment score", "repair_alignment_trajectories.png")

png(file.path(figures_dir, "final_repair_alignment_scores.png"), width = 1200, height = 700)
barplot(
  summary_table$final_repair_alignment_score,
  names.arg = summary_table$scenario,
  las = 2,
  ylab = "Final repair alignment score",
  main = "Final Repair Alignment Score by Scenario"
)
grid()
dev.off()

print(summary_table)

This workflow supports the article’s central methodological claim: relief should be judged against delayed consequences and fundamental capacity, not only immediate symptom reduction. The R outputs help readers compare quick-fix dependency with repair-oriented transition.

Back to top ↑

GitHub Repository

The companion repository for this article should help readers model fixes that fail through quick-fix loops, delayed consequences, capacity depletion, repair scenarios, dependency indicators, distributional effects, and recurring-pattern diagnostics using synthetic datasets and reproducible workflows.

articles/fixes-that-fail/
├── python/
│   ├── fixes_that_fail_workflow.py
│   ├── fixes_that_fail_baseline.py
│   ├── quick_fix_loop_model.py
│   ├── delayed_consequence_simulation.py
│   ├── capacity_depletion_model.py
│   ├── relief_vs_repair_scenarios.py
│   ├── dependency_diagnostics.py
│   ├── distributional_side_effects.py
│   ├── validation_checks.py
│   └── run_all_fixes_that_fail_workflows.py
├── r/
│   ├── fixes_that_fail_diagnostics.R
│   ├── fixes_that_fail_plots.R
│   ├── quick_fix_visualization.R
│   ├── delayed_consequence_tables.R
│   ├── relief_repair_comparison.R
│   ├── dependency_summary.R
│   └── run_all_fixes_that_fail_workflows.R
├── julia/
│   ├── nonlinear_fixes_that_fail.jl
│   ├── delayed_feedback_fix_model.jl
│   └── capacity_repair_simulation.jl
├── sql/
│   ├── schema_problem_symptoms.sql
│   ├── schema_quick_fixes.sql
│   ├── schema_delayed_consequences.sql
│   ├── schema_capacity_stocks.sql
│   ├── schema_repair_scenarios.sql
│   ├── schema_model_runs.sql
│   └── schema_outputs.sql
├── rust/
│   └── fixes_that_fail_diagnostics_cli.rs
├── go/
│   └── relief_repair_runner.go
├── cpp/
│   ├── efficient_delayed_consequence_scan.cpp
│   └── dependency_threshold_solver.cpp
├── fortran/
│   └── recurrence_fixes_that_fail_model.f90
├── c/
│   └── low_level_fix_feedback_engine.c
├── docs/
│   ├── modeling_principles.md
│   ├── article_notes.md
│   ├── fixes_that_fail_framework.md
│   ├── diagnostic_questions.md
│   ├── ethics_and_distribution_notes.md
│   ├── assumptions_and_limitations.md
│   └── responsible_use.md
├── data/
│   ├── synthetic_problem_symptoms.csv
│   ├── synthetic_quick_fixes.csv
│   ├── synthetic_delayed_consequences.csv
│   ├── synthetic_capacity_stocks.csv
│   ├── synthetic_repair_scenarios.csv
│   ├── synthetic_model_runs.csv
│   └── synthetic_outputs.csv
├── outputs/
│   ├── README.md
│   ├── figures/
│   └── tables/
└── notebooks/
    ├── python_fixes_that_fail_walkthrough.ipynb
    └── r_fix_failure_visualization_placeholder.ipynb

This repository structure supports the article’s central argument: a fix should be evaluated not only by its immediate relief but by its delayed consequences and effect on fundamental capacity. The data/ folder separates problem symptoms, quick fixes, delayed consequences, capacity stocks, repair scenarios, model runs, and outputs. The python/ and r/ folders support quick-fix modeling, delayed consequence simulation, capacity depletion, relief-versus-repair scenarios, dependency diagnostics, and distributional side-effect analysis. The julia folder supports nonlinear delayed-feedback examples. The sql folder defines schemas for symptoms, fixes, consequences, capacity stocks, repair scenarios, and outputs. The lower-level language folders provide scaffolds for diagnostics, delayed consequence scanning, recurrence modeling, and low-level simulation.

Back to top ↑

Back to top ↑

Back to top ↑

Why Fixes-That-Fail Thinking Matters

Fixes-that-fail thinking matters because it reveals the hidden cost of short-term relief. A fix can appear successful, win praise, reduce pressure, and still make the system more fragile. The symptom falls, but the stock depletes. The crisis quiets, but capacity erodes. The budget balances, but maintenance backlog grows. The message lands, but trust remains unrepaired. The process speeds up, but burden shifts outward.

The lesson is not that quick fixes are always wrong. The lesson is that quick fixes must be treated as temporary stabilization, not as structural solution. A responsible system asks what delayed consequences the fix may create, who will experience them, and what deeper repair must begin immediately.

This archetype is especially important for institutions because institutions are often rewarded for visible action within short time horizons. Systems thinking expands the horizon. It asks whether the fix is reducing the problem or reproducing it. It asks whether relief is buying time for repair or buying permission to postpone repair.

Fixes that fail remind us that doing something is not the same as changing the system. The real test of a fix is not whether the symptom improves today. It is whether the system becomes less likely to produce the symptom tomorrow.

Back to top ↑

Related Articles

• Limits to Growth
• System Archetypes and Recurring Patterns
• Shifting the Burden
• Dynamic Complexity and Policy Resistance
• Delayed Feedback and Policy Timing
• Stocks, Flows, and the Architecture of Change
• Sensitivity Analysis for System Interventions
• Leverage Points and Places to Intervene in a System

Further Reading

• Senge, Peter M. The Fifth Discipline: The Art and Practice of the Learning Organization. Doubleday/Currency.
• Senge, Peter M., Kleiner, Art, Roberts, Charlotte, Ross, Richard B., and Smith, Bryan J. The Fifth Discipline Fieldbook: Strategies and Tools for Building a Learning Organization. Doubleday.
• Kim, Daniel H. and Anderson, Virginia. Systems Archetype Basics: From Story to Structure. Pegasus Communications.
• Wolstenholme, Eric F. “Towards the Definition and Use of a Core Set of Archetypal Structures in System Dynamics.” System Dynamics Review.
• Meadows, Donella H. Thinking in Systems: A Primer. Chelsea Green Publishing.
• Sterman, John D. Business Dynamics: Systems Thinking and Modeling for a Complex World. Irwin/McGraw-Hill.
• Forrester, Jay W. Industrial Dynamics. MIT Press.
• Homer, Jack B. and Hirsch, Gary B. “System Dynamics Modeling for Public Health: Background and Opportunities.” American Journal of Public Health.

Back to top ↑

References

• Forrester, J.W. (1961) Industrial Dynamics. Cambridge, MA: MIT Press.
• Homer, J.B. and Hirsch, G.B. (2006) “System Dynamics Modeling for Public Health: Background and Opportunities.” American Journal of Public Health, 96(3), pp. 452–458. Available at: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1470514/
• Kim, D.H. and Anderson, V. (1998) Systems Archetype Basics: From Story to Structure. Waltham, MA: Pegasus Communications.
• 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/
• MIT OpenCourseWare (2013) Introduction to System Dynamics. Massachusetts Institute of Technology. Available at: https://ocw.mit.edu/courses/15-871-introduction-to-system-dynamics-fall-2013/
• Senge, P.M. (1990) The Fifth Discipline: The Art and Practice of the Learning Organization. New York: Doubleday/Currency.
• Senge, P.M., Kleiner, A., Roberts, C., Ross, R.B. and Smith, B.J. (1994) The Fifth Discipline Fieldbook: Strategies and Tools for Building a Learning Organization. New York: Doubleday.
• Sterman, J.D. (2000) Business Dynamics: Systems Thinking and Modeling for a Complex World. Boston: Irwin/McGraw-Hill.
• Wolstenholme, E.F. (2003) “Towards the Definition and Use of a Core Set of Archetypal Structures in System Dynamics.” System Dynamics Review, 19(1), pp. 7–26.

Back to top ↑