Meta · 16 min read

Causal Models

Explain systems with mechanisms and counterfactuals: what would change if this part failed, so debugging becomes structured rather than vibes-based.

Why this exists

Correlation and mythology fill the gap when you lack a causal model: restart everything, blame the last change, or trust a dashboard vibe.

Causal models make mechanisms explicit: A influences B through a process you can test. That is how you turn a trail of networking concepts into an operational skill.

This lesson closes the internet path by converting knowledge into diagnosis.

Axioms & primitives

01A causal model names parts, relationships, and what would differ if a part changed.
02Good debugging proposes interventions that would falsify hypotheses.
03Symptoms can share causes; causes can produce multiple symptoms.
04Time order matters: effects do not precede their causes in the model's story.
05Replace 'feels related' with 'mechanism connecting them.'

Learning objectives

After this lesson you should be able to:

Construct a short causal chain for a web page load from DNS to paint.
Derive three falsifiable hypotheses from a vague outage report.
Distinguish a correlation ('broke after deploy') from a mechanism.
Choose an intervention (ping, dig, curl -v, traceroute) that tests a specific link in the chain.

Progressive depth

Read the layers in order for a full explanation. Or open the layer you need.

Intuition

When a site fails, amateurs change many things at once. Causal thinkers change one thing in the model at a time: if DNS were wrong, dig would show it; if TLS failed, curl would stop before HTTP; if the app failed, you would still connect and see a status.

The internet path you just studied is a ready-made causal skeleton. Use it.

Feeling sure is not a model. A model makes risky predictions.

Formal shape

Represent the system as nodes (DNS resolver, TCP handshake, TLS cert check, HTTP handler, DB) and edges (depends on / produces).

For a symptom, list candidate broken edges. For each, name an observation that would be different if that edge were the culprit.

Prefer interventions that split the search space: can we reach the IP? Is port open? Is cert valid? Does HTTP return? Does the app log an error?

Update the model when reality disagrees. A model that cannot be wrong is not empirical.

Worked examples

Symptom: browser spinner, no status. Chain check: DNS answer? TCP connect? TLS? Only then HTTP. A 500 would mean you got further than this symptom implies.

Symptom: only mobile users fail. Hypotheses: different DNS, IPv6 path, TLS interception, captive portal. Mechanisms differ; tests differ.

Symptom: after deploy, API latency spikes. Correlation with deploy is a clue, not a verdict. Mechanism might be N+1 queries, missing index, or lock contention. Measure to see which.

Networking classic: large downloads hang, small ones work. Causal pointer toward MTU/PMTUD rather than 'TCP is broken.'

Edge cases

Multiple simultaneous faults violate single-cause trees. Still start with the simplest failing edge.

Heisenbugs and race conditions require models that include time and scheduling, not only static boxes.

Social causation (on-call handoffs, bad runbooks) is real; include it when the mechanism is human process.

Do not confuse storytelling after the fact with the model you had before the tests. Write hypotheses first when you can.

Mental models

Domino chain
Tip one domino and watch which others must fall. Ask which domino is missing when the end does not fall.
Counterfactual screwdriver
Ask: if I changed only X, would Y still happen? That question separates causes from decorations.
Fault tree
Work backward from the bad outcome to necessary upstream failures. Eliminate branches with tests.

Common misconceptions

Myth
If two things move together, one causes the other.
Reality
They may share a cause, or the arrow may be reversed, or the link may be coincidental.
Myth
Restarting fixed it, so we understood it.
Reality
You may have cleared state without identifying the mechanism. The bug can return.
Myth
A causal model must be mathematical to be useful.
Reality
A clear box-and-arrow mechanism with testable predictions is already a model.
Myth
More dashboards mean better causal understanding.
Reality
Dashboards without mechanisms produce alert archaeology.

Exercises

Work these without looking up answers first. Check yourself against the intent notes.

Exercise 01
User report: 'Gmail is down.' Build three hypotheses at different altitudes and a test for each.
What good looks like
Local network; DNS; app/service region. Tests: other sites, dig/ping, status page/curl.
Exercise 02
Draw a causal chain from typing https://example.com to seeing text, naming at least six mechanisms from this path.
What good looks like
DNS, TCP/QUIC, TLS, HTTP, HTML parse, CSS/JS/render; maybe CDN/cache.
Exercise 03
A change to CDN cache settings correlates with login failures. Propose a mechanism involving cookies or Cache-Control, and a test.
What good looks like
Shared cache storing Set-Cookie/personalized responses; inspect Cache-Control/Vary; reproduce with two users.

Uncertainty notes

Original meta-toolkit pedagogy; no catalogue URL attach required.