Taylor Bosier

Capacity: committing before you know demand

Contract volume has to be committed for the quarter before anyone knows what the quarter holds. Commit too little and you buy the rest on the spot market at whatever it costs that week. Commit too much and you pay a shortfall fee on trucks you never used. The fleet is finite, so every load you promise one lane is a load you cannot promise another.

A two-stage program with recourse over 400 demand scenarios. The capacity constraint binds only the first stage, so the second stage separates by lane and the Lagrangian decomposes. One price on capacity goes out to every lane, each answers with its own newsvendor quantile, and the plan is where those quantiles meet the fleet. The last step prices it against planning on mean demand, and against knowing demand in advance.

Pricing: quoting a lane that barely runs

A lane with five loads should not be quoted with the same confidence as a lane with a hundred, but it still needs a price today. The question is how much of the network's rate a thin lane should borrow, and how much of its own history it has earned the right to trust.

A three-level Bayesian hierarchy settles it. The shrinkage weight below is how much of the quote came from the lane itself. Click a lane, or use the arrow keys, to price it.

Dispatch: pickup and delivery routing

Eleven orders, four trucks, and nothing can be delivered before it has been picked up. Finding a set of routes that works is easy. Finding a cheap one fast enough that a dispatcher will actually wait for it is the job.

220 candidate routes are built by randomized cheapest insertion under precedence, capacity and range. A greedy pass then covers the orders with the cheapest disjoint set it can build. When the fleet cannot reach all of them, the readout says how many it served. It is a heuristic: no LP relaxation, no dual bound, no gap. In production that is what a solver is for. Switch to Data for the instance an operator would receive, or Assignment to see drivers matched to chains of orders.

Staffing: who covers what, every fifteen minutes

A coffee house already knows who is working today. What nobody has time to work out, at 07:40, with a queue out of the drive‑thru, is which of the six people on the floor should be standing where — and who is about to hit two hours on the headset and has to be rotated off it.

The roster is an input, not an output. This assigns stations, not shifts. Every quarter hour it solves a min‑cost assignment of the people on the floor to the seats available — five service stations, three deferrable cleaning jobs, a break, or nothing — against a demand forecast per station. Unserved orders roll into the next quarter hour, so falling behind at the drive‑thru makes the drive‑thru more expensive to ignore.

Each quarter hour is solved exactly, by the Hungarian algorithm over a worker×seat cost matrix. Two honest caveats come with that. The quarter hours are solved in sequence, each taking the queues the last one left, so the day is greedy — no globally optimal roster, no bound. And an assignment problem needs a cost per seat that does not depend on who fills the other seats, whereas true marginal coverage does: what a second barista adds depends on how fast the first one is. So the seat price is a linearisation, charging earlier seats at the average proficiency of the trained staff on the floor. The matrix is solved exactly; the matrix is an approximation of the service model beside it. That gap is where a production version would change formulation. Pick any assignment in the schedule to see the arithmetic that chose it.

Training, the two‑hour cap on the headset and the break are hard: they remove seats from the matrix rather than charging for them. Minimum coverage is only a dominating penalty, so with more stations than staff it can lose — and when it does, the readout says how many quarter hours went short rather than quietly drawing a store that was fully covered.

Invented instance. The store, the seven staff, their proficiencies and the demand curve are all made up for this panel. No employer’s store, staff or volumes appear here.

Contract intelligence: documents to decisions

The rebate terms are three paragraphs buried in a sixty page contract, and a contract estate can run to many thousands of them. Reading all of them into a model costs a fortune and still misses things, so the job is to find the two paragraphs that matter and price the rebate off those.

Below is one contract going all the way through: it arrives, gets read, lands in the lake, is chunked into a vector index, and an agent pulls back only the clauses it needs. The rebate owed falls out at the end.

None of this is real data. The contract, the customer and every figure on it are invented, and the percentages are arithmetic over those invented figures. It is a drawn walkthrough of the shape of a retrieval pipeline I built in industry, not a window onto one.