How far can you trust the numbers?

A few things learned the hard way while building the LP, kept here because the mistakes were more instructive than the successes:

• Every balance needs a stock. Lead, release and transit times are fractions of a month, split across two months by weight. Without a stock to absorb the fraction, the LP is forced into exact month-by-month equalities between flows with different weights, and the cheapest way to satisfy them is to oscillate shipments between a high and a low value every other month (an IIR-filter instability, not a bug in the sense of wrong code — a legitimate optimum of a badly posed problem). Every site carries a small stock (finished stock at every production site and warehouse, input stock at every CMO that buys, a buffer at every consumption point) specifically to remove this degree of freedom.
• Scale the quantities. The example network's flows are in the hundreds of thousands of packs a month; solved directly, HiGHS's numerical tolerances (tuned for values near 1) make the interior-point method far less reliable. Every quantity in the LP is in units of 10,000 pack-equivalents instead.
• No HiGHS LP-format variable name may start with e followed by digits — the reader parses e12 as a floating-point exponent, not a variable. Every variable prefix in the code was chosen to avoid this (the re-routing variable is g, not the more obvious e).
• The solver fallback cascade exists for a reason. The interior-point method without crossover is several times faster than simplex on a problem this size, but occasionally fails numerically on an unusual network. solve() tries interior-point without crossover, then with crossover, then the dual simplex, and only reports failure if all three do.
• The warm-up and run-out exist to stop the horizon's edges from distorting the plan. Without them, the LP would either start with no pipeline filled (starving the first months) or end by building stock it will never use (since nothing after the horizon needs it). The warm-up has the first month's demand and fills the slowest pipeline; a site may make at most 110% of what the first month needs, so the plan does not quietly pre-build stock before it even starts.
• The capacity investment optimiser needed a different model, not a longer timeout. The first attempt wrapped the month-by-month LP (~20,000 rows) in a mixed-integer search over build decisions; even one binary variable took over a minute to find any answer better than "build nothing", because every branch re-solves the whole relaxation. Raising the time budget made this slower, not more useful. The fix was a smaller, purpose-built annual-resolution model (src/invest.js), not a bigger timeout.
• A quieter bug: annual rates look like annual totals until you check. Early in building that annual model, a pack of unmet demand was costed once per year-slot rather than once per pack — the model was comparing a one-time capex against roughly a twelfth of the real annual cost of a shortfall, so it almost always chose not to invest, even when investing was worth tens of millions of dollars. The "builds when the margin clearly beats the capex" case below exists specifically to catch a regression of this kind.