What Happens When It Goes Down

Between 2005 and 2020, nearly every operations software demo pitched at quarries, elevators, and hauling outfits hit the same speed bump. The screens were impressive, the reports were in color, and then somebody's father, or the scale operator who'd run the window for nineteen years, asked the question the salesman least wanted: what happens when it goes down?

The answer was always a version of "offline mode, syncs right up when you're back." The owners who found that answer thin, and walked, spent the next twenty years being called late adopters. Look hard at what they were actually pricing. They turned out to be right.

7:04 on a Tuesday

Here's the morning the question was about. First truck crosses the scale at 6:50. At 7:04 the ticketing screen freezes, then offers a gray box: cannot reach server. Maybe the overnight update hung. Maybe the DSL line to the pit office dropped, the same line that drops every hard rain. The cause doesn't matter to the nine trucks now idling at the gate, burning their drivers' first and best hour.

The scale operator does the only defensible thing. She pulls a legal pad out of the drawer, waves trucks onto the scale, and writes: truck number, customer, product, weight off the indicator, time. The line moves. By 11:00 the system is back, and the outage gets remembered as a four hour annoyance.

It wasn't. It was a billing event that ran for weeks. Those 38 pad loads now have to be keyed by hand, Thursday, from handwriting produced at queue speed. One page of the pad rode home in somebody's jacket. Two loads for the paving job got written without a job number, so they billed at the account's default rate instead of the bid rate. And say three loads never made it into the system at all: at 23 tons and $12.75, that's roughly $880 gone, not because paper failed, but because paper was demoted to emergency equipment and nobody treats emergency records like money.

The point of record moved

Step back and look at what that generation of software actually did to the operation. For decades, the record of a load was made at the window, on paper, by the person watching the truck. No boot time, no login, no signal, no license check. The point of record and the point of work were the same place.

The new system moved the point of record to a server, which is to say, someplace else. And it did this at exactly the kind of site that infrastructure reaches last. Think of a pit two ridges past the end of reliable cell coverage, an elevator office wired for a fax machine, a shop where the router sits under a coffee maker. The busiest sixty seconds in the whole operation, a loaded truck on the scale, now depended on all of it holding.

Put the claim plainly, since a vendor would dispute it: for a scale window, software that's up 99 percent of the time is worse than paper. Not almost as good. Worse. The missing one percent doesn't land on a quiet February afternoon, because outages cluster with load: updates break things on Monday mornings, connections strain when the season does. And each outage mints a batch of records in a second, untrusted format that someone must merge later, which is exactly the clerical failure the software was bought to end. The offline mode rarely earned its keep. It tended to sit untested until it mattered, to duplicate tickets on sync, and once it had burned an office twice, nobody trusted it enough to use it.

The risk was never at the window

Paper has real weaknesses. Every one of them lives downstream of the window: the ticket that sits in a drawer for three weeks, the keying backlog, the handwriting argued about in a rate dispute, the book that never gets reconciled against the invoice run. That's where the leaks are, and always were.

The pitch for that era of software named those problems and then attacked the one place paper was unbeatable, the moment of capture. It fixed the drawer by breaking the counter. The owner who declined wasn't sentimental about carbon paper. He looked at a gate that loads sixty trucks a day, asked what one down morning costs in idled trucks and scrambled records, and did availability math the salesman hadn't. His pad in the drawer was the disaster plan. He just declined to make the disaster possible.

The carbon book is the offline mode

Servers didn't get perfect. Software stopped needing to stand between the truck and the record of the truck. AI can read the operation's own paperwork, as written, after the fact. So the capture layer goes back where it belongs: the ticket book at the window, which has no downtime to have.

That's the shape Termco is built on. The scale house writes tickets the way it always has, drivers install nothing, and the paper gets digitized, as written. Tickets that break a rule get flagged, billing rules and reference data live in one place, and invoice totals assemble from tickets that cleared. If the internet at the pit dies for a morning, the gate doesn't notice, because the gate never needed it. The record was made in ink at 7:04, same as at 6:50.

flowchart TD
    A["Loaded truck on the scale"] --> B{"Where is the record made?"}
    B -- "2005-2020: in the software" --> C{"Server reachable?"}
    C -- "yes" --> D["Ticket prints"]
    C -- "no" --> E["Legal pad at queue speed"]
    E --> F["Keyed Thursday, minus what's lost"]
    B -- "at the window, in ink" --> G["Carbon ticket, every time"]
    G --> H["Read and checked afterward"]

Ask about the pad

Two tests, depending on which side of the bet you took. If you run one of these systems, ask your scale operator where the pad is. She'll produce it in under ten seconds, which tells you she expects to need it. Then pull the pad pages from the last outage and count how many of those loads you can find on an invoice. If you stayed on paper, your point of capture has run thirty years at full availability. The only thing left to fix is everything downstream of the drawer. Send 10-20 sample tickets to hi@termco.ai and we'll send back what we find within 48 hours.

Either way, the question from the demo deserves a better answer than it ever got. Here's one: it shouldn't be able to go down.