Mission Sustainability Planner

As a logistics planner, I need to know how many days of fuel we have at current tempo right now, not after an hour of manual arithmetic that's probably wrong anyway.

As Logistics Program Manager for a 500+ person organization, I inherited a supply system built on fixed resupply intervals with no connection to actual consumption. Planners scheduled fuel and ration deliveries retroactively based on current inventory, not by burn rate, not by operational tempo, not by what the data said.

The result was predictable: shortages that took vehicles offline mid-operation, and a ~$4M annual operating budget padded with arbitrary buffers because no one could predict what would be consumed. The money sat uncommitted. The vehicles sat broken. And every resupply decision was a guess dressed up as a schedule.

What was missing was not judgment. Nothing connected force structure and operational tempo to what the force would burn, so the planners, who were capable, were doing the arithmetic by hand or not at all.

Before writing a line of code, I ran structured user interviews with planners, drivers, and operators to map where the pain was. Three findings shaped everything that followed:

• No real-time endurance visibility. Planners couldn't answer "how many days of fuel do we have at this tempo?" without manual arithmetic that was usually wrong by the time it was done.
• Calendar-driven resupply, not consumption-driven. Trucks went out on a fixed schedule regardless of what was being burned, producing both early resupply waste and missed windows that caused shortages.
• Budget buffers set by precedent, not prediction. Uncommitted funds accumulated in over-allocated line items because leadership couldn't trust any forecast well enough to reallocate.

Operators did not know they were approaching a shortage until they were in one. The fix belonged upstream, in what planners could see, before it belonged in how much fuel got delivered.

One constraint shaped everything downstream. Operators in the field do not have reliable internet. A hosted web app, however convenient to build, would have been unusable at the point of decision. Discovery surfaced this early, and it set the deployment model: the tool had to be downloadable, runnable offline, and operable on whatever machine a planner had on hand.

I built a single-file HTML/JS MVP that modeled resource consumption as a function of three variables: force structure (vehicle count and type), operational tempo, and per-class burn rates derived from field data. The model generated:

• Daily burn rates per supply class (fuel, water, rations, ammunition)
• Days-of-supply at current stock levels, with the binding constraint (the bottleneck resource) surfaced explicitly
• Resupply timing and quantity recommendations, shifting the system from calendar-based to consumption-based
• A structural capacity check that flagged when organic carrying capacity was insufficient regardless of stock level, a design decision that surfaced a class of problem planners hadn't recognized

I iterated the model twice on planner feedback, refining the operational tempo multipliers and the output format. Its outputs then fed a Power BI decision-support dashboard used in senior leadership briefings, which also tracked forecast against recorded consumption by supply class. Ammunition forecast error fell 11% against the calendar-based estimates it replaced, and ration waste fell 18% once orders followed the forecast instead of the calendar.

The continuous-fulfillment model, which pushed resupply before shortages rather than after, came directly from a user research finding: drivers reported that running dry was the single most disruptive event in a training cycle, and they consistently preferred smaller, more frequent resupply over waiting for a full load.

The first working model produced a flat burn rate. It took force structure and per-class consumption rates and projected them forward at a constant pace. That is a reasonable first approximation, and it was wrong in the way that matters most, because it looked authoritative.

Consumption does not run flat. It tracks how hard the force is working: how far vehicles move, how long generators run, how many people are out. A week of heavy activity and a week in place burn nothing like the same fuel, and a flat model averages them into a number that is never right on any given day. Planners spotted it immediately, because they already knew this in their bones. The tool was telling them something their experience contradicted.

The fix was to make operational tempo a first-class input rather than an assumption baked into the rates. Low, medium, and high tempo each carry their own multipliers per supply class, derived from field data, so the same force structure produces different burn rates depending on what it is being asked to do.

That change also opened a door I had not expected. Once tempo was an input, the operations section could feed their own projected tempo for the coming weeks straight into it. The forecast stopped being a projection of the present and became a plan against the schedule the unit was going to run. The accuracy gain came less from the model getting cleverer than from it finally being able to consume something operations already knew.

As a planner working out of the back of a vehicle at 0200 with no white light authorized, I need to read a sustainment forecast without wrecking my night vision or lighting up our position.

The first working version had a light interface: dark text on a pale background, which is what every planning tool looks like. It tested fine at a desk. It failed the first time somebody opened it in the field at night.

A bright screen in the dark is a problem in two directions at once. Looking at it destroys the dark adaptation the operator spent twenty minutes building, so they are effectively blind for several minutes after looking away. And the light itself carries. A pale screen in open terrain is visible far past the position it is sitting in.

That reframing produced three specific decisions:

• Black canvas, red foreground. Red preserves dark adaptation: rod cells are least sensitive at the red end of the spectrum, so an operator can read a full sustainment picture and still see when they look up. Red also carries less at distance than the blue-white a standard interface throws.
• An operator-controlled brightness slider. "Dark enough" is not a fixed value. A covered vehicle, open ground under moonlight, and a shelter with the flap down are three different conditions, and the operator is the only one positioned to judge which they are in. The control is a single slider, set once and remembered, with no menu to navigate in the dark.
• Status stopped being carried by hue. A monochrome red display has no green-amber-red scale to spend, so state is communicated by luminance step plus an explicit text label instead. This was forced by the palette, but it made the tool more legible under load, not less. A tired planner reads LIMITING faster than they interpret an amber cell.

The same constraint drove the packaging. The tool is a single HTML file: no framework, no build step, no network calls, and no external fonts. Everything it needs is in the file, because there is no connectivity at the point of decision, and anything the tool has to fetch is a feature that does not exist when it matters.

• −18% ration waste, measured against monthly consumption from prior training events. Ordering rations to the forecast instead of the calendar eliminated the over-ordering that had food expiring unused
• Asset endurance doubled, from 48 to 96 hours, through a process change rather than the tool itself. Once the forecast showed fuel as the binding constraint, I redesigned resupply around it: off-cycle, low-profile fuel resupplies scheduled between the 48-hour bulk runs. With fuel no longer the binding constraint, endurance ran out to the next one: ammunition, at four days
• Ammunition forecast error −11%, tracked in Power BI. Same model, a different supply class: the dashboard compared forecast ammunition demand with recorded consumption. The narrower range let senior leaders commit budget buffers they had been holding against uncertainty, and accept tempo they would previously have declined