28 KiB
From Babbage to Babcock
Or: how I learned to stop worrying and love the pipe
Standard disclaimer: if you are here for the juicy math and not the rambling frog, it is at the bottom. I do not open posts by flinging equations at your face like some kind of unhinged math flasher. The formal objects are always there. They will wait. Boing.
One day, a coolant line stopped being a coolant line.
This is what my brain does. It takes something that is supposed to stay normal — a pipe, a valve, a pressure gauge — and refuses to leave it alone. Normal people look at a coolant line and think "good, the server is not on fire." I looked at it and thought: wait. Is this a sentence?
A coolant line is simple. Hot thing gets hot. Liquid carries heat away. Pump keeps things moving. Machine does not melt.
That should have been the whole story.
Unfortunately, I kept looking at it.
And then the pipe became a sentence.
Not metaphorically. More like structurally. A pipe has direction. It has resistance, pressure, state, failure modes. It participates in a graph. It knows, in the brutal language of physics, whether the system it belongs to is still balancing.
And then the annoying thought arrived, as they do, at exactly the wrong moment:
What if the cooling system is not just removing the consequences of computation? What if it is already doing a second kind of computation underneath it?
Great. Thanks, brain.
That is where this post begins. Not with an answer. With a pipe that would not stay quiet.
The Babbage part
Babbage is the comfortable origin story.
Computation as machinery. Gears. Tables. Mechanical logic. Numbers go in. Operations happen. Numbers come out.
This is the lineage we know how to talk about. It leads, eventually, to silicon, chips, GPUs, datacenters, and all the glowing machinery we now treat as weightless because the hard parts are tucked behind dashboards that nobody actually looks at until something is on fire.
But computation is not weightless.
Every bit flip has a cost. Every accelerator cluster is also a very expensive way of converting electricity into heat and then pretending that was not the point. That heat does not disappear because the model got smarter. It has to go somewhere. Air, water, refrigerant, coolant, pumps, valves, heat exchangers — all the unglamorous plumbing that keeps the symbolic machine from becoming an accidental furnace.
We built a $400 billion industry and bolted a boiler room underneath it.
Babbage gives us the symbolic engine. But the datacenter also needs Babcock.
The Babcock part
I am using Babcock less as a single person and more as an industrial ghost.
Babcock means boilers. Pressure vessels. Tubes. Heat. Containment. Failure. The world where energy does not politely become abstraction just because we named a thing "compute."
A boiler is not a symbol machine. A boiler is a pressure argument with consequences.
Babbage calculates. Babcock remembers the calculation must be paid for in heat.
Once I saw that split, liquid cooling started looking different.
A coolant loop is not decorative infrastructure. It is a mandatory thermodynamic coupling layer. If it gets ignored, blocked, misread, or decoupled, the machine crosses into throttling, shutdown, damage. The computer cannot opt out of its cooling system.
So why are we treating that cooling system as passive plumbing?
(I will be honest: this question annoyed me more than it should have. It felt like watching someone run a very expensive calculation and then throw away half the output because it came out as heat instead of numbers.)
The bad idea (which is not actually the bad idea)
Here is the version that sounds bad:
With mild changes, coolant lines can become data lines.
That framing is wrong. It makes people imagine Ethernet in a pipe. Tiny packets with headers paddling through a rack like very determined boats. That is not it. Please do not build that.
The better idea is stranger and more boring at the same time:
The coolant loop is already a physically coupled state system. You can read it as one.
Pressure, flow, temperature, valve position, pump speed, branch impedance, vibration, thermal delay, failure signatures — all of that is already part of the loop's state. The coolant system is already doing work. The question is whether some of that unavoidable thermodynamic work can also carry useful structure.
Not: can a pipe send data?
Rather: if a pipe must already carry the consequences of computation, can we use that mandatory coupling as a computational witness?
That is where it stopped being a gimmick for me.
The old water computer hiding in the wall
This is not completely without ancestors, which I find very reassuring. It is nice to know someone was already doing a version of the thing before I had the annoying thought.
Vladimir Lukyanov built a hydraulic analog computer in the 1930s. The Soviet water integrator. It solved differential equations using water level, flow, and resistance. Not metaphorically. The water did the math because the system was arranged so that its behavior corresponded to the equation.
A water computer. That ran in the Soviet Union. In the 1930s. And we sort of just... forgot about it.
That matters. It reminds me that computation has never belonged only to electronics.
Sometimes computation is a gear. Sometimes a voltage. Sometimes light in a cavity. Sometimes water looking for a level. Sometimes, apparently, a Soviet plumbing installation that nobody put in the museum tour.
I am not proposing we rebuild Lukyanov's machine. I am saying we already built enormous fluid systems around the machines and cities we depend on. We just have not been reading them correctly.
The reservoir trick
The idea I actually care about comes from reservoir computing.
In reservoir computing, you do not train the whole physical system. You drive the system, let its internal dynamics transform the input, and train only a readout layer. You are not programming the reservoir. You are listening to it.
Photonic reservoir computing is the version that breaks my brain. Not because photons are magic. Because the posture is different.
It says: let physics do part of the transformation.
That sentence is dangerous to me specifically. I want to put it on a wall.
Because once you accept it, you start seeing reservoirs everywhere, which is a great way to make normal conversations very difficult.
A coolant manifold is a reservoir. A pressure zone is a reservoir. A city water network is a reservoir. A road network under load is a reservoir. A bridge vibrating in weather and traffic is a reservoir.
Not all of them are useful. Not all are readable. Not all should be touched. But the category opens, and once it opens it does not close again.
The question becomes: which physical systems are already being forced, measured, constrained, and stabilized?
Those are candidate substrates.
I have started seeing them on the way to the grocery store. This is fine. Everything is fine.
But before we zoom back in, let me zoom all the way out. Because there is one more reservoir, and it is the biggest one.
The view from the moon
The largest computational device on earth is the weather system.
Nobody built it. Nobody programmed it. It has been running for four billion years without a budget meeting, a steering committee, a single line of code, a Zoom call, or a directive from middle management insisting we recompile the paradigm of physics before the Q3 deadline.
The input signal is solar radiation. The input translators are Earth's rotation, ocean heat capacity, atmospheric composition, terrain, ice albedo, and about forty other things we are still arguing about. The reservoir dynamics are everything meteorology has ever tried to describe. The readout layer is what we call a weather forecast.
We did not design this substrate. We just eventually got good enough instruments to start reading it.
Now here is the thing that made me sit down when I realized it.
The weather system is not separate from the city substrate argument. It is the top layer of it. The city sits inside the weather system. The water network is fed by it. The steam tunnels are responding to it. The road is deforming under it. The demand waves in a city's water grid are partially weather-driven. The hospital steam load spikes with it.
The whole stack, from the top:
weather system ← largest physical reservoir, solar-forced
↓
city water / steam ← civilization-scale reservoir, demand-forced
↓
hospital steam loop ← campus-scale reservoir, load-forced
↓
datacenter coolant ← machine-scale reservoir, compute-forced
Same architecture at every level. Different scale. No CPU anywhere in the stack.
This is what I mean when I say all is computation if you have the correct input translator. Physics does not need to be told to compute. It already is. The question is only whether we have built the readout layer yet.
The weather system has one, imperfect and expensive and still improving.
The city does not yet. That is the gap. That is the whole post.
SCADA was already there
This is where it becomes less science fiction. Which I say with genuine relief because at this point in the idea I was starting to wonder about myself.
Modern infrastructure already has control systems. Pumps report status. Valves expose position. Tanks expose levels. Pressure zones have readings. Alarms fire. Operators intervene. Setpoints change.
The flow is already controlled. The data already exists.
Which means the first step is not to install a surveillance mesh over a city, or build anything new, or write a grant proposal, or convince anyone that water computers are cool again.
The first step is to take the inputs and outputs that already exist, and place them on the topology they belong to.
Stop treating infrastructure telemetry as isolated readings. Start treating it as a topological matrix.
That is the object I am calling the Babcock Matrix.
A Babcock Matrix is the graph-aligned state of a mandatory flow or thermodynamic system. Nodes are pumps, valves, tanks, reservoirs, cold plates, junctions, pressure zones. Edges are pipes, mains, tunnels, coolant lines, bypasses, returns. The state is pressure, flow, temperature, level, actuator position, alarm condition.
The matrix is not just numbers. The matrix is numbers placed back onto the body they came from.
I do not know yet if this is a useful object. I think it is. I am writing it down because writing it down is how I find out. If you have seen this object before under a different name, please tell me immediately so I can cite you and feel less like I invented something weird in my bathroom.
The substrate inversion
People will say: but that is not really computation.
What they usually mean is: that is not the kind of computation I already recognize, and recognizing things is how I know they are real.
I do not think substrate has to mean silicon.
A substrate is any lawful physical medium whose state transitions can be constrained, observed, and made useful. Silicon is a substrate because charge can be disciplined into logic. Optics because photons can be guided, delayed, interfered, and read. Hydraulics because pressure, flow, resistance, storage, and delay evolve under constraint.
A road can be a substrate. A bridge. A pipe.
Not because they are secretly laptops — they are not, do not email me — but because they are physical systems with state, topology, forcing, memory, residuals, and possible readouts.
The city does not fail to compute because it lacks GPUs. It computes differently, because its substrate is water, gravity, pressure, demand, delay, friction, strain, weather — constraint becoming legible.
Failure as a math error
This is the piece that made the whole thing click for me. I was so pleased about it that I told someone at dinner. They were not as pleased. But I think they were wrong.
A pipe rupture does not need to be recognized first as a pipe rupture.
In a topological flow matrix, it shows up first as a conservation failure. Water enters a subgraph. Water exits a subgraph. Some is stored. If those quantities stop balancing beyond tolerance, the graph is telling you something changed. The pipe does not need to announce it broke. The graph fails to close. A hidden outlet appears. Flow disappears into an unmodeled sink.
The alarm is secondary.
The first event is a math error.
That is the kind of infrastructure I want. Not infrastructure that waits to be visibly broken and then sends someone a ticket. Infrastructure whose equations fail loudly enough to guide repair before the visible part happens.
A road that screams
Once you see this, it jumps domains. And then it just keeps jumping, which is a problem I apparently cannot stop having.
A road is a material graph under load, weather, vibration, moisture, drainage, traffic, thermal cycling, and time. If you have a topological equation for the road, maintenance changes category.
You are not just patching holes after they appear. You are building a road that screams when it needs repair.
The scream is not mystical. It is mathematical. A road segment has an expected vibration signature. It drains a certain way. It deforms within a certain envelope. It responds to temperature and load within bounds. When that stops being true, the road has already reported its wound.
The pothole is only the late-stage user interface.
I love that sentence. I think about it more than is reasonable.
The pothole is the late-stage user interface of a failed topology.
Not the surveillance city
This is also why I am not describing the usual IoT answer. The IoT answer and I have a complicated relationship.
A lot of smart city thinking is surveillance with better branding. More cameras. More phone tracking. More license plate readers. More household inference. More private behavior turned into someone else's data exhaust. More dashboards that imply that if you just knew more things about more people, the city would somehow fix itself.
It would not. And that is not what I am describing.
The city does not need to watch its citizens to know where it is breaking.
A pipe does not need to identify a household to know conservation no longer closes. A bridge does not need to identify pedestrians to know its vibration modes are drifting. A road does not need to identify a driver to know its surface is failing.
The point is asset-state minimalism: read the physical variables required to determine whether the asset remains inside its lawful envelope. Ignore identity. Avoid behavioral inference. Keep the readout local where possible. Let the infrastructure diagnose itself.
Not the city that watches people. The city whose infrastructure can feel itself breaking.
This is, I think, a more useful thing to build. It is also less fun for the companies that sell the cameras, which is probably why it is not the default.
The hospitals are already doing it. They just do not know yet.
Here is the one that keeps me up at night.
Across America, hospitals run steam distribution systems. Have for over a century. Steam for sterilization, heating, humidification, pressure systems, surgical suites. Big installations. Heavily instrumented. Already monitored. Already controlled. Already producing thermodynamic state continuously, around the clock, whether anyone is paying attention to it as a substrate or not.
These are not edge cases. These are major urban hospitals. Academic medical centers. Regional health systems. The steam channels are there. The pressure differentials are there. The flow state is there. The thermodynamic potential is just sitting in the pipes, doing its job, going unread as anything except "the steam is fine."
Now here is the part that got me.
You would not need to modify the hardware. Not a single valve. Not a single sensor. The instrumentation already exists. You would need a software update and a readout layer. That is it. You would be reading something that is already happening, not building something new.
Which means the barrier to entry is not steel and civil engineering. It is attention.
And here is where it becomes less abstract and more uncomfortable:
A lot of people in America use the emergency room for basic care because they cannot afford anything else. They go in. They get treated. They skip the bill. Not because they are irresponsible — because the math does not work and the bill would break them anyway. The ER absorbs the loss. The hospital absorbs the loss. Everybody pretends this is not a structural problem and then argues about it every few years without fixing anything.
But if a hospital could rent out thermodynamic reservoir capacity from its existing steam infrastructure — to a startup that needs cheap reservoir compute, to a research group, to whoever — that revenue does not have to go to shareholders. It could go to a gap fund. A sliding scale. A no-bill threshold for people who cannot pay.
No new infrastructure. No surveillance. No identifying anyone. Just: the steam is already doing thermodynamic work. We can read that work. Someone will pay to use it. And that payment can go toward making sure the person who came in with a broken arm at 2 a.m. does not leave with a $4,000 bill they will spend three years ignoring.
I am not saying this is easy. I am not saying the regulatory path is obvious or that hospitals would just... do this voluntarily. I am saying the physical argument closes. The substrate is there. The instrumentation is there. The need is there. The only thing missing is treating the pipe as something more than a pipe.
City as Substrate
The hospital is the intimate version of the argument. One campus. One steam loop. One institution whose thermodynamic waste could become its own operating margin.
Now scale it up.
Imagine New York. Not as a skyline. As a hydraulic organism.
Reservoirs. Aqueducts. Tunnels. Mains. Valves. Towers. Pumps. Pressure zones. Demand waves. Stormwater. Wastewater. Heat. Weather. Gravity. Millions of people participating in aggregate flows without needing to be individually identified or surveilled or tagged or logged into a dashboard.
That system is already in motion. Already forced. Already controlled. Already producing state.
A datacenter spends electricity to create artificial state transitions in silicon. A city water network undergoes enormous state transitions because civilization requires it, and civilization does not care if you have the budget for it.
I am not saying New York's plumbing is a GPU cluster. That framing smuggles in the wrong definition of substrate and also would be a very strange pitch to the city council.
I am saying New York's plumbing is a civilization-scale physical reservoir whose dynamics can be made legible. The city is already running the simulation in matter. SCADA is the passive sensorium. The Babcock Matrix is the state representation. The readout is where computation becomes visible.
The city is doing the work. We are just not watching the right output.
Homeostatic homology
Once you lift the system into topology, you can ask a different kind of question.
Not just: where are the pipes?
But: which parts of the system perform the same stability function?
A tank, a reservoir, a pressure-regulated district, and a coolant buffer look physically different. But under perturbation, they may play related roles. They buffer shock. They restore gradients. They preserve pressure. They maintain thermal viability. They keep the larger system from leaving its safe envelope.
That is what I mean by homeostatic homology: recurring equivalence between parts of a controlled physical network that perform the same stability-preserving role.
A city is full of these. A datacenter is full of these. A body is full of these.
Here is where I have to physically stop myself, because my brain immediately tries to jump from pipes to biology to compression to formal verification to governance to whether frogs have homeostatic homology and how many ponds that would require and whether n is large enough.
So I will keep the claim small.
If infrastructure can be represented as a topological state matrix, we can classify its substructures by how they preserve homeostasis under stress.
That is enough. That is already a lot. I will go lie down.
The map
This all started as a weird sentence:
Coolant lines can become data lines.
But that sentence was only the door. Behind it:
flow control already exists
↓
SCADA provides passive state
↓
state belongs on topology
↓
topology becomes matrix
↓
matrix exposes residuals
↓
residuals expose failure
↓
failure becomes legible before collapse
That is the thing I am trying to name.
Not surveillance. Not magical pipes. Not replacing GPUs with plumbing. Not tiny packets on boats.
A substrate inversion. A way to treat mandatory physical infrastructure as a lawful computational witness.
Babbage gave us the symbolic engine. Babcock gives us the pressure vessel.
The future city may need both: logic above, thermodynamic witness below.
And somewhere between them: a pipe that would not stay quiet.
I do not know if the Babcock Matrix is the right object. I think it is. If you see a hole in it, or you have seen this exact idea somewhere else and I just did not find it yet, tell me. That is literally why I am writing this. I would rather be corrected than comfortable, even when it is about something I got attached to at dinner.
Appendix: The math, for people who want it
Okay. You scrolled. Good. Welcome to the math section, you absolute freak, I mean that with full affection.
I use LLMs as a cognitive prosthetic, which means some of what follows may be wrong. If you see a hole, tell me. That is why I flashed you the math instead of hiding it. Here are the actual objects.
The infrastructure graph
Let the physical infrastructure be represented as a graph:
G=(V,E)where:
V=\{\text{pumps, valves, tanks, reservoirs, junctions, pressure zones, cold plates, road nodes, bridge supports}\}E=\{\text{pipes, mains, tunnels, coolant lines, bypasses, return loops, roads, spans, drainage paths}\}The graph is not merely a map. It is the body of the infrastructure system.
Local state vector
Each node or edge carries a state vector:
s_i(t)=[P_i(t),Q_i(t),T_i(t),L_i(t),A_i(t),\Delta P_i(t),R_i(t),\alpha_i(t)]| Symbol | Meaning |
|---|---|
P_i(t) |
pressure |
Q_i(t) |
flow rate |
T_i(t) |
temperature |
L_i(t) |
level, storage, or local capacity |
A_i(t) |
actuator state: pump, valve, regulator, gate |
\Delta P_i(t) |
pressure differential |
R_i(t) |
inferred resistance, impedance, roughness, blockage, or degradation |
\alpha_i(t) |
alarm, status, or health code |
For roads or bridges, generalize to:
s_i^\text{road}(t)=[\sigma_i(t),\epsilon_i(t),\omega_i(t),T_i(t),M_i(t),D_i(t),L_i(t),R_i(t)]| Symbol | Meaning |
|---|---|
\sigma_i(t) |
stress |
\epsilon_i(t) |
strain or deformation |
\omega_i(t) |
vibration response |
M_i(t) |
moisture |
D_i(t) |
drainage state |
L_i(t) |
aggregate load |
R_i(t) |
roughness, resistance, or surface degradation |
The Babcock Matrix (formal definition)
The observed system state at time t:
\mathcal{B}_t=\begin{bmatrix}s_1(t)\\s_2(t)\\\vdots\\s_n(t)\end{bmatrix}The full topological object:
\boxed{\mathfrak{B}_t=(G,A_G,W_G,\mathcal{B}_t)}where A_G is the adjacency matrix and W_G encodes weighted topology: diameter, length, capacity, resistance, valve constraints, roughness.
The Babcock Matrix is the graph-aligned state of a mandatory flow, thermal, hydraulic, or civil infrastructure system.
Flow-control dynamics
Existing SCADA/BMS control actions become system input:
u_t=[\text{pump RPM},\text{valve position},\text{gate state},\text{coolant setpoint},\text{storage release},\text{bypass state}]External forcing:
d_t=[\text{demand},\text{weather},\text{thermal load},\text{traffic load},\text{storm input},\text{industrial draw}]Infrastructure evolution:
\mathcal{B}_{t+1}=F(\mathcal{B}_t,u_t,d_t,W_G)+\eta_twhere \eta_t is noise, sensor drift, turbulence, unmodeled failures, and stochastic variation.
Reservoir readout
The physical system is the reservoir. The readout layer:
y_t=R_\theta(\mathcal{B}_t,G,W_G)\boxed{\text{let physics transform the state; train the readout}}Conservation residual
For a subgraph S \subseteq G:
r_S(t)=\sum_{e\in\partial^-S}Q_e(t)-\sum_{e\in\partial^+S}Q_e(t)-\Delta S(t)Normal operation: |r_S(t)|\le\epsilon_S
Failure condition: |r_S(t)|>\epsilon_S
\boxed{\text{failure begins as a conservation-law exception}}Rupture as hidden boundary
A rupture introduces an unmodeled edge:
e_\text{leak}:v_i\rightarrow\varnothing \quad \Rightarrow \quad G'=(V,E\cup\{e_\text{leak}\})The model still assumes G=(V,E), so the rupture appears first as:
\lVert\mathcal{B}_{t+1}-F_G(\mathcal{B}_t,u_t,d_t)\rVert>\tau\boxed{\text{the pipe does not need to announce that it broke; the graph fails to balance}}Homeostatic objective
H(\mathfrak{B}_t)=\lambda_P\lVert P_t-P^\ast\rVert+\lambda_Q\lVert Q_t-Q^\ast\rVert+\lambda_T\lVert T_t-T^\ast\rVert+\lambda_L\lVert L_t-L^\ast\rVert+\lambda_A\lVert A_t-A^\ast\rVertSystem attempts to preserve: H(\mathfrak{B}_t)\le h_\text{safe}
Failure is not merely damage. It is departure from the viable homeostatic envelope.
Homeostatic homology
Two subgraphs S_i,S_j\subseteq G are homeostatically homologous when:
S_i\sim_H S_j \quad \text{if} \quad \Phi_H(S_i,\delta)\approx\Phi_H(S_j,\delta')\boxed{\text{homeostatic homology is topology under the demand to stay alive}}Screaming infrastructure residual
Let \mathcal{L} be the lawful constraint operator. Failure residual:
\rho_t=\lVert\mathcal{L}(X_t,G)\rVertA road screams when \rho_t>\tau_\text{repair}.
\boxed{\text{the pothole is the late-stage user interface of a failed topology}}Privacy-preserving readout constraint
The desired readout:
Y_t=R_\theta(X_t,G)Privacy condition:
\frac{\partial Y_t}{\partial P_t^\text{personal}}=0\boxed{\text{infer asset state from physical state, not personal identity traces}}Hospital steam (formal objects)
A hospital steam loop as a pressure/heat/work graph:
G_{steam}=(V_{plant},E_{steam})V_{plant}=\{\text{boilers, heat exchangers, sterilization loads, humidifiers, valves, traps, condensate returns, sensors}\}E_{steam}=\{\text{steam mains, branches, condensate lines, district-energy tunnels, hospital utility corridors}\}Local thermodynamic state per edge:
s_i^{steam}(t)=[P_i(t),T_i(t),\dot{m}_i(t),h_i(t),x_i(t),A_i(t),R_i(t),\alpha_i(t)]| Symbol | Meaning |
|---|---|
\dot{m}_i(t) |
mass flow rate |
h_i(t) |
specific enthalpy |
x_i(t) |
steam quality / dryness fraction |
R_i(t) |
thermal/hydraulic resistance, fouling, trap degradation |
Useful thermodynamic work potential per branch:
\dot{W}_{usable,i}(t)\le\eta_i(t)\,\dot{m}_i(t)\,[h_{in,i}(t)-h_{out,i}(t)]Hospital thermodynamic matrix:
\mathfrak{H}_t=(G_{steam},A_{steam},W_{steam},\mathcal{H}_t)Ethical value chain:
\boxed{\text{thermodynamic residual value} \rightarrow \text{hospital operating relief} \rightarrow \text{care capacity}}Historical anchors
Babbage's Difference and Analytical Engines: symbolic-mechanical computation lineage. Babcock & Wilcox: industrial pressure-vessel and boiler lineage. Lukyanov's Soviet water integrator (1936): prior hydraulic analog computation. Reservoir computing literature: substrate-independent computation via physical dynamics and trained readout layers.
If you cite this, the post lives at froginnponds.substack.com. ORCID: 0009-0000-1594-0095. A machine-readable CITATION.cff is available in the companion repository.