HOPPER MATH
What it's designed to do: Sizes a railcar fleet for a planned shipping schedule, and refuses when the history can't support the answer.
[ THE PROBLEM IN THE FIELD ] internal · product spec
Frac sand moves by rail in covered hoppers. Demand swings and fleets don't. Lease too few cars and the pad runs short; lease too many and they sit while someone pays for them. At a terminal without silos the railcar is the silo, so how long a car stays depends on how fast the pads draw sand as well as on the railroad.
What it's designed to do.
internal · product spec and gate record
- The engine takes the shipping plan for each lane and the history of how long cars took to turn.
- The engine sizes the fleet for that plan. When the app is built, every input will open to the trace rows behind it.
- The engine is tested to refuse when the history can't support a sizing, and to say why.
- Fleet and spares views are not built yet.
[ WHO IT'S DESIGNED FOR ] by role · internal · product spec
Fleet manager
Will own the lease book and the car traces, and recommend whether to lease, renew or return.
Supply planner
Will declare the shipping plan per lane and compare one plan against another.
Approver
Will sign off a sizing as the basis for a lease decision.
Finance reader
Will read the idle and short car-days and keep the decision record.
Auditor
Will check that the record and the packet verify.
[ WHAT'S PROVEN ] internal · gate record
An independent second implementation agreed on 400 of 400 test plans, byte for byte.
[ HONEST STATUS ]
Sizing engine proven. Fleet, spares and the app are not built yet.
[ SCREENS ]
No screens are published for HOPPER MATH on this site.