Part VIII. Lesson 34. Commissioning and Acceptance.
Every part of this program was preparation. Commissioning is where the bill comes due. The quality of the system gets tested twice, in two different places, against two different owners. Once at our shop before it ships, on our terms: the factory acceptance test. Once on the customer's floor, on the customer's terms, under real load: the site acceptance test.
Neither one is a formality. The first session proves the system. The second designs what keeps it running after we drive away.
Test scripts exercise the system end to end: every routing decision, every handshake, every exception path. You write the script that makes the response not come back in time, on purpose, and watch what the system does. Catch it before it ships.
Stated up front, in numbers, about sustained performance rather than one good run. The system holds the design target across a real run under real load. The WMS handshake gets confirmed at real volume, not on the bench. Then customer sign-off.
A system that makes rate for one minute isn't a system that makes rate. I have watched a machine sail through a demo on a slow afternoon and then choke the first time a truck showed up three hours late and the volume all hit at once. The stated rate is the target. The real constraint is the bad day, the peak before a holiday, the wave that stacks up because something upstream slipped. So when we accept a system, we prove it against the design target sustained, under real load, not on a slow minute of a quiet shift.

Calling one good run a passed test. Rate validation is statistical and sustained, not a single clean minute you happened to catch. If the system can't hold the design target across a real run under real load, it hasn't been proven, it's been demonstrated on a good day. Those are different, and the customer finds out which one you gave them at the next peak.
It's 2 a.m. The system just stopped and you're the only maintenance person in the building. What do you need on the shelf, in the documentation, and on the phone to get it running again before the morning wave? Design the service model from that moment backward, not from a template forward.
A system doesn't end at go-live. Someone maintains it for years, and the service model is the design deliverable that decides whether they can.
Designed to the customer's actual maintenance capability, not a generic template.
Stated cleanly so it isn't argued after a failure instead of before one.
Who can reach the system to diagnose it. Assigned here as a service decision; the network is L21.
Spares by criticality tied to L26, O and M docs, and a walkthrough of every serviceable component.
Riverside's SLA and SAT expectations drive the commissioning plan, and our firm runs the FAT. Write the FAT scripts to exercise the scan-to-WMS-to-divert handshake and, deliberately, the exception path when the WMS doesn't answer inside the one-second window Ray confirmed.
The SAT criteria are Riverside's, stated as numbers: sustained 20 CPM against the design target under real wave-release load, the misdirect rate proven down from the roughly three percent Dana described, and the confirmed one-second latency proven under peak load. Then the service model, designed to what Michael's team of one can actually do at 2 a.m.
Next: I finished the program. Am I ready to run one alone?