The First Output Is a Test

The dangerous moment in an automation project is not always the obvious failure. It is the first output that looks plausible enough to skip review. A clean answer can hide a messy assumption if nobody checks what the system had to ignore to produce it.

At Compass, the first version of my ordering calculator did exactly what it was asked to do. It pulled recent sales, current inventory, and supplier lead times, then turned those inputs into proposed orders. The problem was that the real operation had constraints the model did not know yet: supplier behavior, order timing, batch logic, and the judgment operators had been carrying in their heads.

So the first output was useful because it was wrong in a specific way. It showed where the system understood the workflow and where it was still guessing. The team review was not resistance to automation. It was the missing domain knowledge becoming visible.

The pattern that worked was simple: generate a draft, compare it against how the team would make the decision manually, ask why the gaps existed, encode the real constraint, and rerun it. Each cycle made the recommendation less impressive on paper and more useful in the operation.

That is the difference between a prototype and a system. A prototype can produce an answer. A system can explain why the answer changed after it met the floor, the shelf, the supplier, and the person who still has to live with the result.

The goal is not a perfect first version. The goal is a shorter path from messy work to trustworthy defaults. Treat the first output as evidence, not authority, and it can tell you exactly what the automation still needs to learn.