EITRI LOAD
What it's designed to do: Runs a rail-to-truck transload terminal, from inbound railcar to empty release.
[ THE PROBLEM IN THE FIELD ] internal · product spec
At a rail-to-truck sand terminal without silos, the inventory sits in railcars. Car events come from the railroad, weights from the scale house, the spout position from the loadout operator, orders by phone and rates from contracts. When those live in separate tools, book inventory drifts from the scale, jobs get promised that the lanes can't load, and a charge arrives that nobody can trace.
What it's designed to do.
internal · product spec and gate record
- Designed to keep one record for the terminal, from the railcar arriving to the empty going back.
- Designed to tie every truck that leaves to the car it loaded from.
- Designed to check a job against the lanes and the sand on hand before it is promised.
- When the app is built, every number will open to the events behind it.
- The engine is tested to refuse rather than guess, and to say why.
[ WHO IT'S DESIGNED FOR ] by role · internal · product spec
Terminal manager
Will run the site and decide which jobs to take.
Loadout operator
Will run a loading lane and move the spout from car to car.
Scale house
Will check trucks in and out, weigh them and print the tickets.
Dispatcher
Will match truck calls to jobs and replan when a train runs late.
Sand owner
Will see its sand by grade and car, and what it is charged, and why.
Billing
Will keep the rate cards, run invoices and work the refused lines.
[ WHAT'S PROVEN ] internal · gate record
Its gated refusal tests each check the exact reason given.
[ HONEST STATUS ]
Engine built and gated. V1 app in build.
[ SCREENS ]
No screens are published for EITRI LOAD on this site.