RoleProject Architect · Individual Contributor (convex optimization formulation)
TagsConvex Optimization · Digital Twin · Simulation · Supply Chain
Timeline2020 — 2022

Digital twin of the network

When a lane went down or a plant dropped below planned capacity, nobody could say in advance which stores would empty or when — the damage surfaced weeks later and several nodes away from where it began, so the link back to the original failure was easy to miss entirely. The first thing we built was a digital twin of the network. Using the client's real production, inventory, transport, and sales data, we reconstructed the network node by node — every production unit, DC, transfer point, and store, with the actual lanes and lead times between them — so it could faithfully replay historical periods. That let us test any proposed decision against what actually happened, and then against scenarios that didn't. Crucially, the twin also breaks things on purpose: take a lane out for two weeks, hold a plant at 60% capacity, push a shipping window back, and watch which stores run dry, how far downstream the effect travels, and how long recovery takes. That turned "this is a risk" into a ranked list of the failures that actually move the needle — and showed which ones were worth carrying buffer stock against.

Network-wide convex optimization

At the core of the system was a network-wide optimization engine, which I formulated and built. Given a demand forecast and the current network state, it produces the production, transfer, and replenishment plan that best balances the two competing costs — solved as a single convex program across the full network rather than region by region. The objective is a weighted trade-off between the cost of holding excess inventory at every node and a heavy penalty on store-level stockouts, with the relative weight deliberately exposed as a business dial rather than a hidden model parameter: turn it toward service and plans pre-position more stock, turn it toward capital and they run leaner, and planners can view the whole frontier instead of arguing over safety-stock settings one SKU at a time.

The formulation encodes the real constraints of the network — per-period production ceilings (including degraded states, so a unit running at reduced capacity is modelled directly), committed client production plans and their earliest start dates, storage limits at every node, permitted transfer lanes, and multi-period transport lead times. Keeping the formulation convex was a deliberate design choice: it solves reliably at full network scale and returns more than a plan, since the solution also surfaces which constraint is binding — so when a plan can't hit the service target, the model says whether the blocker is a specific plant's capacity, a lane's lead time, or a production start date, turning an inventory debate into a concrete capital or scheduling decision.

Adaptive policies & validation

Running alongside the optimizer was a layer of adaptive decision policies. The optimizer is optimal for the forecast it's handed, but real weeks deviate from forecast, so we used the digital twin to develop policies that learn from thousands of simulated seasons — including disrupted ones — and re-decide sensibly in conditions no forecast anticipated. These complement the optimizer rather than replacing it.

To validate everything, we scored each policy inside the twin against the same historical periods using the client's own planning metrics — store-level stock-out ratio, shelf time and inventory ageing, and total inventory held — and benchmarked three approaches head to head on the same network, demand, and constraints: what the client actually did historically, what their existing planning rules would have done, and what the optimization and learned policies recommended.