The most fun homework assignment I've had in college so far is a 1949 reference. Our group at UVG is building a hydraulic computer that simulates the Guatemalan economy by routing colored water through tanks and pipes. Each tank is a sector. Each pipe is an intersectoral flow. The whole thing has to physically conserve mass, which means the math behind it has to conserve mass too. That last part is mine. The project is led by Professor Benjamín Leiva at Universidad del Valle de Guatemala, in the framework of the Macroeconomía Intermedia course. Calibrated from Banguat's 2013 Cuadro de Oferta y Utilización (COU). I work on the data-analysis side, automating the calibration that turns the official COU into the parameters the machine's pipes and reservoirs are sized against. ## Why a hydraulic computer in 2025 In 1949 A.W. Phillips built the original MONIAC: a hydraulic computer that simulated the British economy by routing colored water through a network of tanks and pipes. Sectors were reservoirs, intersectoral flows were pipe diameters, savings and exports were drains. It was both a research instrument and a teaching device. Watching water move makes a flow identity intuitive in a way that a spreadsheet never does. The Guatemalan version inherits the same intent. As an academic instrument it lets the team test what the structural relationships of a Latin American economy actually look like when they have to physically conserve mass at every node. As a public-facing artifact it gives non-economists a way to see how production, consumption, taxes, imports, and final demand connect. A working hydraulic model is also an honest stress test of the input-output table underneath: if the water doesn't balance, neither does the math. The COU comes from Banguat as two large matrices plus a value-added sheet. CO maps producers to products (who makes what). CU maps products to users (who buys what). VA maps activities to factor income (how much each sector pays in wages, profits, taxes). To turn that into pipes and reservoirs we need a clean directed graph at the activity-by-activity level (sector to sector, not sector to product), with mass conserved at every node. That's the calibration problem the data side of the project is solving: matching the model's pipe sizes to the actual monetary flows in the data. An economy is a flow system. Drawing it as one means making the math actually conserve mass at every sector, not just at the macro total. ## What it produces A directed monetary graph at the sector level. The 20 highest-VBP activities form the closed system the team is currently pushing toward physical fabrication. 20 cylinders for the dominant sectors, plus external nodes for imports and margins on one side and final demand on the other. Each pump's caudal (litres per minute) is proportional to the monetary flow it represents. Thresholding at 50 L/min keeps only the pumps the physical PoC will actually be built around. Zoom in on a single sector and the entradas-salidas identity becomes legible. AE003, one of the larger agricultural activities in the model, routes factor income (wages, gross operating surplus, mixed income) and supplier purchases on the left into a balanced output of final demand and inter-industry sales on the right. The widths of the bands are the actual calibrated values. The full webapp at [maquina-hidraulica-cou.vercel.app](https://maquina-hidraulica-cou.vercel.app/) carries all 105 sectors, the full input-output matrix heatmap (a giant grid where each row is a sector buying from columns and selling to columns), per-sector calculation traces with formulas, the RAS reconciliation (a standard technique that nudges every cell of the matrix until row and column totals match the targets), and the side-by-side validation against the professor's manual reference. The two slices above are the public sneak peek. The link is the whole thing. ## The two-rescaling move The COU itself is an accounting identity. For each product, supply equals use. For each activity, output equals inputs plus value added. Exact in the published tables. The trick is that the published tables are product-by-activity, while the hydraulic model needs activity-by-activity, and the conversion between the two is what introduces error. The fix is two coupled rescalings. The CO rescaling distributes each activity's basic production across the products it dominates. The CU rescaling distributes each product's use across the activities that consume it dominantly. Both use a 5% relevance threshold. Both renormalize within the kept set. The product of the two rescalings is the *base producida*, the activity-and-product-specific value that drives every downstream computation. Without the double rescaling, the long tail of trivial flows either inflates the dominant flows (no filter) or drops mass that should have been redistributed (filter without renormalization). Either way, the water doesn't balance. A few methodological details earn their weight. The 5% threshold is implemented at 0.0495, not 0.0500, because the professor's Excel rounds 4.95% up to 5.0% in display and lets it pass. Faithful automation needs to reproduce that behavior, not the strict mathematical floor. Non-market products in the public sector (administración pública, educación pública no-mercado, salud pública no-mercado) are flagged as exceptions, because their margins, imports, and net taxes are zero by SCN 2008 convention, and a uniform formula would distribute mass to columns that should stay empty. The VA sheet has subtotal columns interleaved with the 105 real activities, with no formal header to mark them. An automatic detection routine identifies them by checking whether a column equals the running sum of the prior real activities within tolerance, rather than hard-coding positions that could shift between vintages. The implementation runs in two languages. R was the first pass, a course exercise in RMarkdown with the same two-rescaling logic. Python is the production version: properly packaged, golden tests against the professor's hand-calibrated reference activity, a Quarto report that emits HTML and PDF, and the Next.js webapp linked above. Both implementations agree with each other and with the professor's manual reference within tolerance. I built the second one before the first one was clearly working, partly because I wanted to find out where I'd been wrong by building it twice in different runtimes. That trick caught a few real bugs. A physical hydraulic model fails immediately if the water doesn't balance. There's no way to round to zero. Water either arrives at the next reservoir or it doesn't. That hard constraint is what forces the double-rescaling discipline. An economy that doesn't conserve mass per sector can't be drawn as a flow system, and the model itself becomes the validator of the math. The R prototype and the Python production pipeline implement the same procedure in different runtimes. When both produce numbers within tolerance of the professor's manual calibration, that's evidence the methodology was implemented correctly, not just that one runtime happened to fit. When they disagree, the disagreement is a flag. Cheaper than a formal proof, and faster to react to than a single golden-path test suite. Residual errors after calibration aren't bugs to chase to zero. Some sectors carry structural limitations of the COU itself: real estate's weight in fixed capital formation, financial services and the SCN 2008 treatment of imputed interest, certain professional services with thin intermediate inputs. The pipeline reports those residuals and tags them with the economic explanation, instead of smoothing them into a uniform rounding. The honest residual is more useful to the fabricators than a fake-clean number. ## What this gave me I came in expecting to learn economics. I spent more time learning what an industrial-engineering toolbox does to a national accounts table when nobody told the tools to behave themselves. Process flow, mass balance, calibration, sub-team handoffs. Same primitives that govern a manufacturing line, just with money instead of fluid. Phillips's 1949 insight, that a monetary economy IS a flow system, still holds up. Drawing the economy as a flow system means writing code that conserves mass at every node, validating it against an independently-computed reference, reporting the residuals honestly when the data has structural limits, and handing a calibrated parameter set off to the people who fabricate the physical thing. None of those moves are exotic on their own. What's distinctive is doing all of them on a national accounts table and trusting the output to size physical pipes.