Why functional intent is critical in acceptance testing

Over the course of my career, I’ve participated in industrial automation projects from multiple vantage points—plant personnel, system integrator, original equipment manufacturer (OEM) and even across different integrators with varying execution models. One recurring issue cuts across all of these perspectives: how acceptance criteria are defined and, more importantly, who defines them.

The ambiguity of acceptance testing

In industrial environments, acceptance criteria are often formalized through factory acceptance testing (FAT) and site acceptance testing (SAT). FAT is typically conducted at the integrator’s facility or the OEM’s shop, while SAT occurs after installation at the end user’s site. While these terms are widely used, what actually constitutes “acceptable” performance during FAT and SAT is far less consistent.

There is frequent ambiguity around scope. For example, some organizations consider startup and commissioning activities to be part of SAT, while others treat them as separate, billable phases. If these distinctions are not explicitly defined before contract execution, they inevitably become points of friction later.

Frameworks for functional verification

In more regulated industries, such as food and pharmaceuticals, acceptance criteria are significantly more structured. Frameworks like good manufacturing practices (GMP) introduce installation qualification (IQ), operational qualification (OQ) and performance qualification (PQ). These are not arbitrary distinctions.

• IQ verifies that the system is installed correctly.
• OQ verifies that the system operates as intended.
• PQ verifies that the system performs consistently over time.

This model highlights an important principle: acceptance is not a single event, but a layered verification of installation, functionality and performance.

But, even in this structured approach, a critical question remains: What defines “operates as intended”?

That answer should come from two foundational documents—the functional specification and the control narrative.

The functional specification describes how the process or machine is expected to operate, typically from a high-level, process-oriented perspective. The control narrative translates that intent into detailed control logic, explicitly tying behavior to specific devices and instrumentation, often aligned with the piping & instrumentation diagram (P&ID).

These documents form the basis for meaningful acceptance testing. Without them, FAT and SAT risk becoming procedural checklists rather than true validation exercises.

And, yet, in practice, they are often missing.

The cost of missing documentation

On a recent controls upgrade project, the integrator was contracted to deliver FAT and SAT procedures, along with execution support. However, no functional specification or control narrative existed.

As the project progressed, the end user requested to review and schedule the FAT. The lead engineer, recognizing the gap, asked for any documentation defining system functionality. None was available. He proposed developing a control narrative as a change order, but the request was declined due to budget constraints.

Get your subscription to Control Design’s daily newsletter.

Faced with this limitation, the integrator produced factory-acceptance-test procedure focused narrowly on verifiable elements within scope—wiring, I/O checks and communications. The procedure was approved; the FAT was executed; and it was formally accepted.

The problems surfaced during SAT.

Once installed, the system did not behave as the end user expected. Without clearly defined functional criteria, there was no shared baseline for “correct” operation. What had passed FAT was never truly validated against intended process behavior.

Shifting responsibility

The end user had allocated one week for installation, loop checks and SAT. The effort ultimately extended to two-and-a-half weeks. Additional integrator resources were required, expanding from two engineers to six during the final stretch. Because the contract only covered one week of SAT support, the overrun resulted in a significant number of change orders.

This outcome was not the result of poor execution; it was the result of undefined expectations.

When the owner does not define acceptance criteria, the responsibility implicitly shifts to the contractor. And contractors, rationally, will define acceptance in a way that minimizes their risk exposure, not necessarily in a way that ensures operational success for the end user.

That is the core issue.

Acceptance criteria should not be an afterthought or a contractual checkbox. They should be deliberately defined by the owner, grounded in clear functional intent and agreed upon by all parties before execution begins.

Without that alignment, FAT and SAT become exercises in proving that a system was built, not that it works.

You can listen to Control Intelligence's interview with Patrick Bunn here.