The Red Asterisk

The clerk is keying Tuesday's paper into the system and the screen won't let her past the third ticket. Net weight is a required field. There's a red asterisk beside the box and a patient little message at the top of the form: please enter a value to continue.

The ticket in her hand says what happened. Three loads of pit run from the Highway 9 borrow pit to the Hendricks driveway job, priced by the load, driver's initials in the corner, the foreman waved the last one in around 4:30. Nobody weighed anything. There's no scale at the borrow pit. There has never been a scale at the borrow pit, which is exactly why the job was quoted by the load in the first place.

The form has one box and the box wants tons. She looks at it for a second, types 22.00, and moves on, because there are forty tickets left and the trucks run again tomorrow. The software logs a complete, validated record. By the end of the season it holds a few hundred of them.

The form is an opinion about your work

Somebody designed that screen, and they designed it around one transaction: a truck crosses a certified scale, gross minus tare makes net, the net gets a product code and a job number, done. For most of your loads that's the truth. The software's mistake was promoting it from the common case to the only case, with a red asterisk as the enforcement.

Because the rest of your operation never fit that shape. The borrow pit counts loads. The water truck bills by the hour. The loader operator calls four buckets ten yards, close enough for a driveway, and everyone involved has agreed it's close enough for forty years. A farmer hauling his own corn out of a field weighs exactly nothing. Drivers, asked where the weight was supposed to come from, said the plain thing drivers say: we didn't weigh the truck, we counted three loads. The form's answer never changed. A value is required to continue.

Required fields were sold as discipline. The demo called it data quality: no more blank tickets, no more holes in the record. But validation can only check that a number is present and shaped like a number. It can't check that the number was measured. The field doesn't collect data your operation declined to produce. It manufactures it, one plausible entry at a time, and files it next to the real thing.

Invented numbers look exactly like measured ones

Here's the claim your software-minded friends will argue with: that required field made your records less trustworthy than the blank it replaced. A blank is honest. A blank says nobody knows, and anyone reading the file later can see exactly what was known and what wasn't. The 22.00 says 22.00, in the same font, with the same confidence, as a weight that came off a certified scale. The database has no way to flag what it forced your own office to invent.

And the number doesn't stay in its box. It rides into the invoice backup you hand a customer who asks, then into the royalty statement, if the pit's landowner gets paid by the ton that leaves his ground. By year end it's load-bearing in the tonnage summary somebody will bid next season's work from. Each stop treats it as a fact, because it looks like one.

Then one of them gets checked. A county engineer, auditing a job that did run across a scale, sorts your haul summary by weight and finds 22.00 sitting there two hundred times in a row, to the decimal. He doesn't conclude that some jobs were honestly priced by the load. He concludes your weights are invented, all of them, including the measured ones, and now a question about one load of pit run has become a meeting about every invoice on the job. One invented column can cost you the credibility of a whole file cabinet of true ones.

There's a quieter casualty too. The field spent years training your most careful person to type a small fiction before lunch, every day, until it stopped feeling like one. No meeting approved that. The asterisk just outranked her.

The pen never argued

Hold the carbon book up against that screen for a minute. The ticket took the day exactly as the day offered it. Three loads, pit run, Hendricks, per Dave on the radio. Where there was no weight, there was no weight, and the blank preserved that fact for anyone who'd ever need it. Paper recorded the day at whatever fidelity the day produced, and for a dispute two Novembers later, that blank is the whole value of the record.

The owners who balked at these systems usually balked right here, and they caught their share of grief for it. The one who heard "the system requires a weight" and answered "we don't weigh those loads" was declining to let a form redesign his pit, or to staff a fiction department to feed it. The vendor's fix, in fairness, was always available: put in a scale, or route every load across the co-op's. Change the operation until the software's opinion becomes true. He did the arithmetic on that and kept the book.

Count the repeats

The test takes ten minutes and a sort button. Pull a season of weights out of whatever system you run and sort the column. Measured weights scatter the way trucks actually load: 23.84, 24.61, 26.12. Invented ones cluster at round numbers and repeat to the decimal. Count the repeats. That's how many times the form refused what happened and your office supplied an alternative, and it marks exactly which jobs' paperwork can't survive a hard look.

More validation won't fix this. The fix is software that takes the ticket as written, which is the posture Termco is built on, and what makes it possible now is simple enough: AI can finally read handwritten paper as it is, so a form demanding the world arrive pre-typed into boxes stopped being the price of getting tickets into a system. The paper stays, the pit stays scaleless, nobody types a made-up number. A ticket gets digitized the way the driver wrote it, and your billing rules decide what the blank means. On a per-load job it means nothing, and the invoice assembles off the count. On a per-ton job, a missing weight gets flagged as non-compliant and surfaces for a person to decide. Reference data holds which jobs price by which unit, so that judgment isn't re-made at keying speed.

flowchart TD
  A["Ticket: 3 loads pit run, no scale"] --> B{"What does the system accept?"}
  B -- "required-field system" --> C["Clerk types 22.00"]
  C --> D["Stored beside the measured weights"]
  D --> E["Invoice backup, royalty report, next year's bid"]
  B -- "ticket read as written" --> R{"Billing rules"}
  R -- "per-load job" --> F["Invoice assembles off the count"]
  R -- "per-ton job" --> G["Missing weight flagged for a decision"]

If you want to see it against your own paper, send 10-20 sample tickets to hi@termco.ai, unweighed per-load ones included, and findings come back within 48 hours.

The clerk's ticket was right. The form was wrong. Of the two records your company kept that Tuesday, be careful which one you keep trusting, because only one of them was there.