Operations teams that build optimization models spend a disproportionate amount of effort on the solver. They evaluate CBC against HiGHS against Gurobi, benchmark solve times, tune MIP gaps, and occasionally invest tens of lakhs per year in commercial solver licenses. The assumption behind all of this is that the formulation is correct and the solver is the limiting factor. In most engagements we've worked on, the assumption is backwards. The formulation contains bugs that no solver upgrade will fix, and the modeling decisions that determine solution quality happen entirely upstream of the solver.
A solver runs on whatever mathematical program you give it. If the inventory balance constraint uses an inequality where it should use an equality, the solver will exploit the slack and let inventory vanish. A Big-M constant set too small means the solver respects an artificial cap on shipments. A reference to a time period that doesn't exist causes a crash or garbage output. In each case, the solver does exactly what the formulation asks.
An inventory network worth ₹3.4 crore
Consider an inventory replenishment problem for an Indian e-commerce operation. One central warehouse supplies 8 regional fulfillment centers, 50 product SKUs, and 12-week planning horizon. The decisions: how much to order at the warehouse, how much to ship from warehouse to each store each week, and what inventory levels to carry at every location.
The model has roughly 15,700 variables. Store-level inventory and ordering accounts for 9,600 (8 stores × 50 items × 12 weeks × 2 variable types). Warehouse inventory and ordering adds 1,200. Shipment quantities add 4,800. Shipment-setup binaries add another 96. Constraints cover inventory balance at both echelons, shipment-setup linking via Big-M, demand satisfaction at each store, and warehouse capacity.
At an average item cost of ₹400, the system manages ₹3.4 crore in inventory. Annual holding cost runs about ₹85 lakh. Weekly ordering and transportation adds ₹6 lakh per year. Open-source solvers solve the full model in under a minute. The solver is not the bottleneck.
Formulation bugs that produce optimal wrong answers
Three bugs appear repeatedly in inventory formulations, whether written by engineers or generated by LLMs. All three produce feasible solutions with valid objective values. The solver reports "optimal" for each.
Inventory balance written as inequality instead of equality. The correct form says: carry-forward from last period plus incoming orders minus outgoing shipments and sales equals the ending inventory. Writing this as ≤ instead of = allows inventory to vanish from the system. The solver will exploit this whenever holding costs are positive, since dumping phantom inventory is cheaper than carrying it. The result is a replenishment plan that systematically under-orders, and the stockouts show up two to three weeks into execution when store shelves empty faster than the plan predicted. Cost: ₹10-20 lakh per year in lost sales on a network this size.
Missing handling for the initial period. Inventory balance for weeks 2 through 12 references the previous week's ending inventory as a variable. Week 1 has no previous week. It uses initial inventory, a known parameter from the current stock count. The common mistake is writing a single constraint for all 12 weeks, referencing I0 for the initial period, where I0 doesn't exist as a variable. Whether this causes a solver crash or silently treats initial inventory as zero depends on your implementation. Either way, week-1 orders are wrong, and the error cascades through the remaining 11 weeks. Cost: ₹5-10 lakh in misallocated inventory during the first quarter.
Big-M set too small in the shipment-setup link. The binary variable indicates whether any items ship to store s in week t, incurring a fixed ordering cost. The constraint bounds total shipment volume by M times the variables. If M is less than the maximum possible shipment (say, the store's total capacity), the solver artificially caps batch sizes. Smaller, more frequent shipments follow, each triggering the fixed ordering cost. Transportation and ordering costs rise by ₹8-12 lakh per year before anyone traces the cause to a single constant in the formulation.
The combined annual cost when these bugs reach production runs ₹20-40 lakh on a ₹3.4 crore inventory base. Upgrading your solver license would not change any of these outcomes.
Two stages instead of one big model
The 15,700-variable model couples warehouse ordering with store replenishment through the shipment variables. A change to one store's demand forecast requires re-solving the entire system, because warehouse ordering might need to adjust. For weekly re-planning cycles where individual stores update forecasts independently, this coupling slows down the feedback loop.
Decomposing into two stages separates these decisions. Stage 1 plans warehouse ordering based on aggregate demand across all stores: roughly 1,200 variables. Stage 2 plans each store's replenishment given warehouse availability from stage 1: roughly 600 variables per store. The 8 store models are independent and solve in parallel. Each stage solves in under a second.
The decomposition doesn't come from the solver. CBC, HiGHS, and Gurobi all solve the coupled model fine for smaller sizes, but the problem sizes explode for coupled models as any dimension increases. The decomposition is a modeling architecture decision. Smaller models are easier to verify: an ops manager can audit the warehouse ordering plan without understanding the store-level replenishment logic. Store managers can adjust their own parameters without triggering a full system re-solve. When a single store's forecast changes mid-week, only that store's model re-runs.
This kind of structural decision, whether to model the system as one program or two coordinated stages, determines how the optimization integrates into weekly operations. The solver will handle either form, but the ops team experiences them very differently.
Simulate, optimize, simulate again
The optimization produces a minimum-cost inventory plan. That plan assumes demand matches the forecast exactly. In practice, daily demand varies, lead times fluctuate, and suppliers miss delivery windows.
LogiModel's simulate-optimize-simulate pipeline tests whether the optimized plan survives real operating conditions. First, simulate the current manual ordering policy against a stochastic demand model to establish a baseline: current cost, stockout frequency, average fill rate. Then run the optimization to generate the minimum-cost plan. Then simulate the optimized plan against the same stochastic demand to measure how it performs when demand deviates from forecast.
If the optimized plan shows frequent stockouts in simulation that didn't appear in the optimization output, the formulation is missing something. The safety stock buffer may be too thin, or the demand variability parameters may need adjustment. The simulation validates the formulation. When the optimized simulation outperforms the baseline on both service level and cost, the formulation has earned the ops team's trust.
This validation loop catches gaps that neither the solver nor a formulation review would surface. A constraint can be mathematically correct and operationally inadequate. The simulation tells you which.
What catches formulation bugs before production
LLMs handle the first stage well. "Plan inventory for a warehouse-store network with 50 SKUs over 12 weeks, minimizing holding, ordering, and stockout costs" maps cleanly to the multi-echelon formulation. An LLM will produce appropriate variable families, objective terms, and constraint structures. Where LLMs fail is structural precision: the equality/inequality distinction in inventory balance, the period-1 index boundary, the Big-M sizing. These are the details that determine whether the formulation is correct or just plausible.
LogiModel's deterministic compiler runs 12 validation passes on the generated LaTeX before producing executable code. The completeness pass catches the period-1 reference to a nonexistent time index. The constraint sense pass flags inventory balance written as inequality when the constraint guidance specifies equality. The Big-M pass warns when the constant is a hardcoded literal instead of referencing a capacity parameter.
When the compiler encounters a LaTeX pattern it cannot parse, it has agentic fallbacks with the specific compilation error as context. The fallbacks know what failed and why, making the fallback more targeted than a fresh translation attempt. If that also fails, the system retries with accumulated error history, learning as it goes so it does not repeat the same mistake. The deterministic compiler handles the majority of formulations. The agentic fallback handles edge cases the compiler's grammar doesn't cover.
A human engineer would catch these bugs too, given enough time. That time costs ₹3-7 lakh in engineering hours and 2-3 months of calendar time per problem type. The compiler catches them in milliseconds, agents fix targeted formulation issues in seconds, and the simulation validates the full result within minutes of the original problem description.
What this changes about inventory operations
For an e-commerce operation managing ₹3.4 crore in inventory across a warehouse and 8 fulfillment centers, the annual cost of undetected formulation bugs runs ₹20-40 lakh. The annual cost gap between manual ordering and optimized replenishment runs another ₹25-38 lakh. Combined, getting the formulation right and keeping it right is worth ₹45-78 lakh per year per network.
None of this value comes from the solver. CBC, free and open-source, solves this model in under a minute. The value comes from the formulation: the constraint families and their sign conventions, the boundary condition handling, the decomposition that makes weekly re-planning practical, and the simulation that confirms the plan works under real demand variability. LogiModel generates the formulation from natural language, validates it through 12 structural passes, decomposes it when the problem structure allows, and tests it against simulated operating conditions. The operations team adjusts safety stock buffers and penalty weights in their own language. The system handles the mathematical engineering underneath.