Every part of this program was preparation. Commissioning is where the bill comes due. The quality of the system gets tested twice now, 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 support you gave through execution was the final test of whether the engineering was complete, and acceptance is where that answer becomes visible to everyone in the building. This lesson runs in two sessions. The first proves the system. The second designs what keeps it running after we drive away.
By the end of this lesson you can set up a factory acceptance test that catches problems before the system ships, hold a site acceptance test to a sustained statistical rate against the design target instead of one good minute, and design a service model that a real maintenance team can actually live with after go-live.
Our firm runs the factory acceptance test. We set it up and we run it, at our shop, before a single beam ships to the customer's floor. That ownership is the point, so hold it. Don't let the customer define our FAT, and don't skip it because the schedule got tight. A problem caught at the FAT is a problem caught before it's bolted down in a live building, where fixing it costs a morning instead of a shift.
The FAT runs on test scripts you write. A script exercises the system end to end: every routing decision, every handshake, every exception path. The scan reads, the query goes to the WMS, the response comes back, the divert fires. Then you write the script that makes the response not come back in time, on purpose, and you watch what the system does. The good day is easy to demonstrate. The FAT exists to prove the bad one, before anyone is standing on the customer's floor watching it happen for the first time.
This is also where the controls standards you set earlier get exercised under a written script instead of discovered in the field. The tagging conventions, the alarm philosophy, the state-machine behavior: how you write those is Lesson 20's subject, and the FAT doesn't re-teach it. What the FAT does is run those standards against a script that touches every path, so a naming gap, or an alarm that points at a symptom instead of the cause, shows up on our bench where it's cheap to fix.
The site acceptance test runs on the customer's floor, against the customer's criteria, because acceptance is the customer accepting. We own the FAT. The customer owns what it takes to accept the system. Those are two tests with two owners, and treating them as one is how a project gets into trouble at the finish line.
The criteria are stated up front, in numbers, and they're about sustained performance rather than one good run. This is statistical rate validation: the system has to hold the design target across a sustained run under real conditions, not make rate for one clean minute and then stall on the next wave. A single good demo proves the system can hit the number once. Acceptance asks whether it holds the number when the volume arrives the way it really arrives.
Real conditions means real load. The WMS handshake gets confirmed in the field, at real volume, producing correct routing decisions under the load the operation actually runs, not just answering cleanly on the bench. A punch list captures every open item that still has to be resolved before acceptance, so nothing quietly gets forgotten. Customer training happens here too: the people who will run and maintain the system learn it before you hand it over, not after. Then customer sign-off on acceptance, saved to the project folder.
The rate and the gap math that define the design target aren't re-derived here. That work has its home in the rate lessons, Lesson 10 and Lesson 25. At the SAT you validate against the target. You don't rebuild it.
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.
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. That's the difference between a system the customer trusts and a system the customer fights us about.
If you want a clean acceptance, then write the SAT criteria into the proposal and the contract before the project starts, in numbers, sustained rate against the design target under real load. Tradeoff: you're committing to a hard bar in writing before you've built anything. Verify: acceptance day becomes a measurement instead of an argument, because everyone agreed what proven means back when nobody was under pressure.
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 after we drive away, and the service model is the design deliverable that decides whether they can. It's a design decision, not an afterthought, and it has three pieces.
SLA first: what response the customer can count on, and how fast. You design it to the customer's actual maintenance capability, not to a generic template. A commitment a one-person team can't physically meet isn't a service level, it's a promise that breaks the first bad night.
Warranty boundary: what's covered and what isn't, stated cleanly so it isn't argued after a failure instead of before one. The line drawn calmly in the contract is the line nobody has to fight about while the system is down.
Remote-diagnostics ownership: who can reach the system remotely to diagnose it, and who owns that access. That decision reaches straight into the question of who owns the OT network, and the network itself, its cybersecurity and its remote-access architecture, is Lesson 21's subject. Here you assign the ownership as a service decision. You don't design the network.
Put together, the service model answers the question every maintenance lead is really asking: when this stops in the middle of the night and I'm the only one here, who fixes it, and how long am I down.
The customer wants a four-hour response SLA, around the clock, and runs a maintenance team of one who has watched two systems fail. What does that one-person reality tell you about the SLA you can honestly offer, the warranty boundary, and the spares you leave on the shelf?
The physical handover. Start with spares. The parts you leave on the shelf follow the criticality strategy: the components whose failure stops the system get stocked, and the ones that don't, don't. That criticality work, the reliability analysis behind which part is critical and which isn't, is Lesson 26's home. Here you hand the spares over, and you hand over the logic behind the list too, so the maintenance team knows why each part is on the shelf, not just that it is.
O and M documentation goes next: the maintenance schedule, the lubrication intervals, the belt-tension intervals, the replacement schedules, all delivered to the customer. Then the part that separates a system a small team can keep alive from one that comes out in six months. The maintenance team gets introduced to every serviceable component and how to reach it. A part they can't get to is a part they can't service, and a service model that forgets that is a template, not a plan.
Go-live support closes it. You're present and reachable as the system comes fully online, because the first real peak is when the surprises show up. You'd rather see them standing next to the customer than hear about them in a phone call the following week. That is the day the whole delivery arc, the FAT, the SAT, the punch list, the training, and the service model, either holds together or shows you where it didn't.
Riverside's SLA and SAT expectations drive the commissioning plan, and our firm runs the FAT. Build it across both sessions.
FAT. Write the test scripts at our shop to exercise Riverside's scan-to-WMS-to-divert handshake, every routing decision to the three doors, and, deliberately, the exception path when the WMS doesn't answer inside the one-second window Ray confirmed. Prove the standards you set for this system under the script, not in the field.
SAT. The criteria are Riverside's, and they're stated as numbers: sustained 20 CPM against the design target under real wave-release load, with the misdirect rate the project exists to eliminate proven down from the roughly three percent Dana described, and the confirmed one-second WMS latency proven under peak load, not on the bench. Run the punch list and the customer training before you ask for sign-off.
Service model. This is Michael's lesson. He's the maintenance lead, a team of one, twenty years on the site, and he's watched two systems come out. He told you why: "I am not telling you this to talk you out of anything. I am telling you because if you design something that my one maintenance guy cannot keep running, we will be back here having this same conversation in two years. I need to understand what it takes to maintain whatever you put in here." Design the SLA, the warranty boundary, and the remote-diagnostics ownership to what one person can actually do at 2 a.m. Hand over the spares by criticality tied to the reliability strategy, deliver the O and M documentation, and walk his team through every serviceable component and how to reach it.
Assemble the commissioning plan in your Riverside note: the FAT script outline, the SAT criteria, the rate-validation method, the punch-list template, the training plan, and the service model with its SLA, warranty boundary, remote-diagnostics ownership, spares handover, and O and M docs.
This is Lesson 34 of thirty-five, and it's where the whole program either gets proven or gets exposed. Every part before this one built toward a system that could be trusted on a bad day and kept running by the people who live with it. Commissioning is where that claim gets tested in front of the customer, and the commissioning plan is where proof and service come together as one deliverable: two gates with two owners, then a service model built for the person who answers the call at 2 a.m. Prove it sustained, hand it over clean, and the system you spent a whole program engineering keeps being the right answer long after you leave the floor.