Warehouse. That is a better place to start than “large language models for combinatorial optimization,” because the business problem is not philosophical. A warehouse has stacks, access directions, priorities, robots, blocked items, and deadlines. Someone has to decide which unit load moves first, which move creates future trouble, and how to search through the possible rearrangements without melting the compute budget. ...
Furnace loading is not the glamorous side of artificial intelligence. No one gives a keynote about choosing which pile of titanium scrap should enter an induction furnace. Which is precisely why it is useful. The paper Enterprise Resource Planning Using Multi-type Transformers in Ferro-Titanium Industry applies a Multi-Type Transformer, or MTT, to two classic combinatorial optimization problems: the Knapsack Problem (KP) and the Job-Shop Scheduling Problem (JSP). It then pushes the method into a real manufacturing allocation case: selecting raw materials for a ferro-titanium furnace batch.1 ...
Queue. That is the least glamorous word in enterprise optimization, which is probably why it matters. A mixed-integer linear programming solver does not usually fail because it lacks mathematical dignity. It fails because the search tree becomes too large, the clock keeps running, and some poor planning system is still deciding which facility to open, which order to allocate, which truck route to approve, or which resource schedule to release before Monday morning starts behaving like Monday morning. ...
Space is not impressed by fluent reasoning. A satellite does not care that an AI agent has produced a confident plan. A ground station cannot magically see through the Earth because the prompt says “ensure connectivity.” A sensor cannot keep collecting images after its onboard storage is full. Orbital mechanics, power budgets, slew angles, data buffers, and line-of-sight geometry are not stakeholder preferences. They are constraints. Reality, annoyingly, still has root access. ...
Probe, Then Commit: Why Solver Tuning Finally Grew Up Planning is where business software goes to meet reality. A factory needs a schedule. A logistics team needs routes. A utility company needs network decisions. A hospital needs staff allocation. The model is elegant, the constraints are clear, and then the solver quietly asks the question nobody put in the PowerPoint: ...
Seats are not just seats. For an airline, a seat can be sold as a cheap restricted fare, a flexible economy fare, or not sold at all. A passenger who cannot buy one fare may upgrade, switch flights, or disappear into a competitor’s booking funnel. Multiply that across routes, departure times, fare classes, demand segments, aircraft capacity, and network balance rules, and the innocent phrase “optimize ticket sales” becomes a fairly effective trap for language models. ...
A shift schedule can be perfectly valid and still be a terrible policy manual. Consider a care-facility manager facing an unpleasant Wednesday: several employees have requested leave, available staffing barely covers demand, and somebody must work a day shift immediately after completing a night shift. The manager makes the assignment because residents still require care. The completed roster records what happened. It does not necessarily record what the facility considers acceptable under normal conditions. ...
A battery pack arrives at an end-of-life processing facility. The easy story says the operator should recover as much value as possible while doing the sustainable thing. The harder story starts five minutes later, when someone has to decide whether to stop, reuse the pack, remove the cover, strip the thermal shield, extract a module, test it, recycle it, or finally admit defeat and dispose of what remains. ...
Ports are already full of automation. Cranes move containers, AGVs follow routes, software coordinates flows, dashboards blink reassuringly at managers who are paid to pretend that blinking equals control. Then one terminal changes its layout, closes a road, adds a vehicle restriction, or introduces a new safety corridor. Suddenly the “automated” dispatching system needs engineers, operations researchers, domain experts, test scripts, model reformulation, solver debugging, and several meetings where everyone discovers that “just adjust the rule” was not, in fact, just. ...
Warehouse. That is a useful place to begin, because combinatorial optimization only sounds abstract until someone has to decide which trucks leave first, which jobs enter which machines, which items fit into which containers, or which solver should be trusted before the deadline starts laughing. In those systems, the hardest question is often not “What is the answer?” It is “Which method should we use for this particular instance?” One algorithm works beautifully on one family of cases and then quietly embarrasses itself on another. This is not a personality flaw. It is the normal condition of optimization. ...