Every project team knows the ritual. You spend weeks at the vendor's site running a thorough Factory Acceptance Test. The equipment performs. The documentation is signed. The asset ships.
Then it arrives on site and — almost without exception — you run the entire test campaign again.
Not because anything broke in transit. Not because the process changed. But because nobody can prove, with objective evidence, that the configuration is still exactly what it was when the FAT was signed off.
That single gap — the inability to carry a validated state from one phase to the next — is responsible for more schedule drag in production projects than almost any other single factor. And it is almost entirely avoidable.
The re-test default
The logic of full SAT re-execution is understandable. Validation teams are accountable for proving that the system on site matches what was designed and qualified. If they cannot prove equivalence, the safest course is to prove everything from scratch.
But "safest" here means safe from an audit perspective — not safe from a schedule or cost perspective. A full repeat SAT on a complex packaging line can involve thirty, forty, even sixty test plans. Each one takes time. Each one pulls engineers off other work. And many of them are testing things that demonstrably have not changed.
The question is not whether to test. The question is: which tests are actually necessary?
What changes between FAT and SAT
The honest answer, for most assets, is: not much. The engineering team is not fundamentally rebuilding the system between factory and site. They are installing it, commissioning it, and verifying it in its real environment.
What does change — and what must be validated at SAT — includes things like network integration, field device connections, and site-specific parameters. What typically does not change is the core program logic, the recipe parameters, the vision system configuration, the SCADA tag structure.
If you could prove, with a signed and time-stamped record, that those unchanged elements are byte-for-byte identical to what passed FAT, you could scope your SAT to the things that actually moved. That is the principle behind baseline-driven validation.
How configuration baselines compress the FAT → SAT gap
The mechanism is straightforward in concept. At the point of FAT sign-off, you capture an immutable snapshot of every in-scope system: PLC programs, SCADA tags, vision configurations, database schemas, machine parameters. That snapshot is cryptographically signed and time-stamped.
When the asset arrives on site, you capture a second snapshot before SAT begins. You then compare the two, automatically, parameter by parameter across every system.
The output is a compare report showing exactly what changed and what did not. That report becomes evidence — objective, auditable, regulator-ready evidence — that the unchanged elements do not need re-testing. Your SAT scope contracts to the delta.
In practice, this approach has reduced SAT test plan counts from 32 plans to 8 on a single pharmaceutical packaging line, saving more than 13 weeks of schedule on that one asset alone.
Who benefits, and how
For validation engineers, the benefit is a defensible, documented basis for scoping decisions. Rather than relying on engineering judgment or verbal assurances that "nothing changed," the scope reduction is backed by objective comparison evidence.
For project managers, it converts the FAT → SAT transition from a full restart into a structured handover. Milestones become predictable. Schedule risk at the SAT phase drops substantially.
For QA and regulatory affairs teams, the compare report is an asset, not a workaround. It is structured precisely for the question regulators ask: "How do you know the system on site is the same system that passed qualification?"
Making it work in practice
Three conditions make this approach reliable. First, the baseline must cover every in-scope system — not just the PLC, but SCADA, vision, databases, and machine parameters. A partial baseline creates partial evidence, which is not enough.
Second, the capture must happen at the right moment. The signed FAT baseline needs to represent the state at formal FAT acceptance, not an earlier engineering build.
Third, the compare must be automatic and exhaustive. Manual comparison of PLC programs across two software versions is slow, error-prone, and not scalable. Automated comparison across all systems simultaneously is what makes the approach practical at real-project timescales.
When all three conditions are met, the FAT → SAT transition stops being a full reset and becomes what it should always have been: a structured, evidence-backed confirmation that the work holds. The same mechanic underpins the broader cost case for pharmaceutical SAT scope reduction and the configuration discipline that holds across IQ, OQ and PQ.