Before accepting an isolator at factory acceptance and again at site acceptance, buyers need a clear answer to one question: which functions does each test actually prove, and which conditions change that proof? Treating FAT and SAT as a single pass/fail gate rather than two distinct evidence sets leaves gaps that surface only after the system is installed and in use. The isolator’s protection objective is product protection through aseptic separation, and the evidence package should be built to demonstrate that objective under the conditions where the isolator will actually run, not only under factory conditions.
Evidence That Belongs at Factory Acceptance
| Requested FAT evidence | Buyer check | Evidence boundary |
|---|---|---|
| Approved protocol | Confirm that each factory test follows an approved protocol | Protocol approval does not replace the test result |
| Predefined acceptance criteria | Confirm that acceptance criteria were set for each test before results were judged | Criteria remain project-specific |
| Raw results | Review the recorded result behind each pass decision | A pass statement alone does not provide the raw evidence |
| Instrument status | Confirm that instrument status is recorded for each test | The record supports interpretation of that test; it does not establish installed-condition performance |
| Software or drawing version | Identify the software or drawing version represented by the test | Evidence applies to the tested version |
| Deviation closure | Confirm that deviations raised during testing have closure records | An unresolved deviation leaves the affected result open |
| URS traceability | Trace each test and acceptance record to the applicable URS requirement | Traceability shows coverage; it does not replace project-specific acceptance criteria |
Factory acceptance exists to challenge what the supplier’s site can represent faithfully: control logic, component function, build quality, software behavior, and the equipment’s response under conditions the factory can reproduce. What FAT cannot represent is anything that depends on the final room, the final utility connections, or the mechanical stresses of transport and installation. This distinction is not a procedural preference; it follows from what a factory setup physically is. A factory mockup of utilities, however close to the project specification, is not the installed utility supply, and a function that depends on that supply has not been proven for its actual operating condition.
This means the buyer’s task at FAT is to confirm that the evidence package demonstrates what is demonstrable now, with enough rigor and documentation that it can be trusted later without repetition. An approved protocol establishes that the test was planned and reviewed before execution, not improvised against the result. Predefined acceptance criteria, fixed before the test runs, prevent criteria from being adjusted to match whatever result the system produced. Raw results, not summary pass statements, let the buyer or a later auditor independently judge whether the result actually meets the criteria claimed. Instrument status matters because a measurement is only as credible as the instrument that produced it. Software and drawing versions matter because an isolator’s documented performance is tied to a specific configuration; a later change invalidates the link between the test and the delivered system unless that change is itself evaluated. Deviation closure matters because an open deviation leaves the associated result unresolved regardless of how the rest of the report reads. URS traceability ties every one of these records back to a requirement the buyer actually specified, which is what allows the buyer to judge coverage rather than just activity.
Where a function depends only on the isolator’s internal design and control logic, and not on the installation environment, FAT evidence for that function can be treated as settled, provided the documentation supports that conclusion. Where a function’s performance depends on something the factory cannot reproduce, FAT evidence establishes only that the function worked under test conditions, not that it will work as installed.
Site Conditions That Must Be Rechecked After Installation
| Condition or function | SAT treatment | Evidence boundary |
|---|---|---|
| Installed utilities | Verify after installation under the approved protocol and predefined acceptance criteria | The supplier-site setup cannot represent the installed utilities |
| Room interfaces | Verify against the actual room interface after installation | Factory evidence does not establish performance at the installed room interface |
| Transport-sensitive functions | Recheck after receipt | A factory pass cannot substitute when transport can affect the function |
| Site conditions | Verify under the applicable site condition | The factory setup cannot represent the actual site condition |
| Functions affected by installation or integration | Recheck after installation and integration | A factory pass cannot substitute when installation or integration can affect the function |
| Functions not affected by transport or installation | FAT need not be repeated when the rationale is documented | The documented rationale must support carryover, and acceptance criteria remain project-specific |
Annex 15 sets the general logic that governs this section: FAT performed at the vendor’s site may be followed by SAT after delivery, and FAT need not be repeated at the site only where transport and installation do not affect the function and that rationale is documented. This is a narrow allowance, not a default. It shifts the burden onto the buyer and supplier to justify carryover rather than assume it.
The reasoning behind this allowance is mechanical. An isolator’s performance depends on pressure cascades, airflow patterns, glove-port integrity, and control responses that interact with the room it sits in, the utilities feeding it, and the physical handling it underwent to get there. A control loop that responded correctly to a simulated input at the factory may behave differently once it is wired into the actual building management system, site power quality, or compressed air supply. An enclosure that held its seal during factory leak testing may have experienced stress during transport or rigging that the factory test cannot have anticipated. This is why installed utilities, room interfaces, transport-sensitive functions, and functions altered by installation or integration cannot inherit a factory pass; the physical thing being tested has changed.
The decision for the buyer is not whether to run SAT, but how to draw the line between what carries over and what must be reverified. That line should be set function by function, not for the isolator as a whole. A function untouched by transport, installation, or room interface may reasonably carry its factory result forward if the rationale is documented and the acceptance criteria remain tied to the project’s own requirements rather than a generic standard. A function that touches any of those boundaries needs its own site-specific protocol, run under actual site conditions, judged against criteria set in advance. ISO 14644-7 frames separative devices generally within this install-test-approve structure but does not supply equipment-specific protocols or limits, which means the buyer cannot treat a general standard reference as a substitute for a project-specific SAT plan.
Functional Challenges for Interlocks, Alarms, Airflow, and Controls
Interlocks, alarms, airflow, and control functions sit at the center of an isolator’s aseptic performance, and each depends on a different kind of proof. An interlock is a safety and containment logic function: it has to be challenged by actually forcing the condition it is meant to respond to, not merely reviewed on a schematic. An alarm has to be triggered under a realistic deviation, not simulated by an operator toggling a signal in software, because the path from sensor to annunciation to operator response is what the buyer actually needs demonstrated. Airflow performance depends on the isolator’s internal geometry interacting with its actual installed environment, including room pressure relationships and supply conditions that a factory setup approximates at best. Control functions govern how the system holds its operating state and responds to disturbances, and their correctness depends on the specific software version and parameter set loaded at the time of test.
The judgment the buyer has to make for each of these functions is the same one that governs the FAT/SAT boundary generally: does this specific challenge depend on something the factory cannot represent? An interlock built entirely into the isolator’s own control system, independent of site utilities or room conditions, is a strong candidate for a function that factory testing can meaningfully prove. An alarm that depends on how the isolator’s control system integrates with the site’s building management or environmental monitoring system cannot be fully proven until that integration exists, because the alarm chain runs through equipment the factory setup does not include. Airflow, almost by definition, is sensitive to the installed room and ductwork, which is why airflow results from a factory environment should be read as a baseline characterization of the isolator’s own performance rather than a prediction of its behavior once installed.
For each of these functions, the buyer should expect a defined protocol and predefined criteria specific to that function, not a single blanket statement that “interlocks and alarms were tested.” A function this close to the isolator’s core protection objective deserves documentation precise enough to show exactly what was challenged, under what simulated or actual condition, and what result was accepted as correct.
Leak, Filter, and Bio-Decontamination Records for the Actual System
Leak testing, filter integrity, and bio-decontamination cycle performance are the three evidence categories most directly tied to an isolator’s aseptic barrier function, and each one is specific to the as-built, as-installed unit rather than to the isolator design in general. A leak test demonstrates the integrity of a particular enclosure at the time of test; it says nothing about a different unit of the same design, and it says nothing about the same unit after a seal has been disturbed by transport, installation work, or a later intervention. Filter integrity testing demonstrates that the specific filter installed in the specific housing met its criteria at the time it was tested, tied to a specific filter identity and installation. Bio-decontamination cycle records demonstrate that a specific cycle, run in the actual chamber geometry with its actual load configuration, achieved the result the protocol was designed to confirm.
This specificity is why records from a design qualification, a similar unit, or a vendor’s general product literature cannot substitute for records generated on the actual system the buyer is accepting. The buyer’s task is to confirm that every leak, filter, and bio-decontamination record presented traces to the serial-numbered unit, the specific filter installed, and the specific cycle run on site, not to a representative or historical result. Where a related isolator project has already addressed how leak testing interacts with other containment-side test methods, that reasoning does not transfer directly here, because the aseptic objective governing this isolator is distinct from a containment leak-testing framework built around operator protection; the buyer should not assume the two acceptance logics are interchangeable.
The condition that should change the buyer’s scrutiny is whether any of these three functions was performed before or after an event that could alter the result: a seal disturbed during installation, a filter installation completed after the leak test, or a decontamination cycle run before the final load configuration was fixed. Any of these sequencing issues means the record in hand may not describe the system as it will actually operate, regardless of how clean the paperwork looks.
Deviation Closure and Traceability Back to the URS
A deviation raised and not closed is not a minor administrative gap; it is an open question about whether the associated test result can be trusted at all. The buyer’s task is to confirm that every deviation recorded during FAT or SAT has a documented resolution, with the rationale for that resolution available for review, not just a status marked as closed. A deviation closed by adjusting the acceptance criteria after the fact undermines the entire predefined-criteria structure that makes the rest of the evidence package credible.
Traceability back to the URS is the mechanism that lets the buyer confirm coverage rather than just activity. Every test performed, whether at FAT or SAT, should map to a specific requirement the buyer actually specified for that isolator and that project. Where a test exists with no corresponding URS requirement, or a URS requirement exists with no corresponding test, the evidence package has a gap that generic protocol language will not reveal on its own. The condition that changes how serious this gap is depends on what the missing or orphaned item governs: a requirement tied to the isolator’s core aseptic barrier function deserves a different level of attention than a requirement tied to a feature with no bearing on that protection objective. The buyer’s review should walk from the URS forward to confirm every requirement was tested, and from the test records backward to confirm every test ties to a requirement, rather than trusting a summary statement that traceability was achieved.
Release Criteria Before IQ, OQ, or Operational Use
The decision at this stage is whether the accumulated FAT and SAT evidence is sufficient to proceed into formal qualification, and that decision depends on whether every function governing the isolator’s aseptic performance has a complete, closed, traceable record at the appropriate stage. A function properly proven at FAT, with a documented and justified rationale for not repeating it at SAT, can be considered settled going into IQ. A function that depends on installed conditions and has not yet been verified under those conditions is not settled, regardless of how clean its factory record looks, because the factory record was never evidence for that condition.
This means the release decision is not a single checkbox but an accounting exercise: for every requirement in the URS, is there a closed test record, run under the appropriate conditions, with resolved deviations, tied to the correct software and drawing version, and reviewed against predefined criteria set before the result was known? Where that accounting is incomplete, the gap should be named specifically; a general statement that “FAT and SAT were completed” does not tell a qualification team which functions were verified under installed conditions and which were not.
For a buyer preparing to move into IQ and OQ, the practical step is to assemble this accounting before qualification begins, not during it. When QUALIA supports a project through this stage, the configuration and acceptance testing the buyer has specified for that particular isolator shapes what the FAT and SAT protocols cover and what evidence is produced at each stage, which is why the buyer’s own URS and acceptance criteria need to be settled and complete before testing starts rather than treated as a formality to be reconciled afterward.
Frequently Asked Questions
Q: How should buyers compare FAT and SAT evidence packages from different isolator suppliers?
A: Compare traceability and completeness rather than the number of tests listed. Each applicable URS requirement should connect to an approved protocol, a predefined project-specific acceptance criterion, the raw result, the tested software or drawing version, and any related deviation closure, with a clear division between factory evidence and site verification.
Q: Can a function that passed FAT be omitted from SAT?
A: Yes, when a documented rationale shows that transport and installation do not affect that function. If installed utilities, room interfaces, site conditions, transport, or system integration can influence it, include a site check under an approved protocol and the applicable project-specific acceptance criteria.
Q: What should happen if the isolator software or drawings change after FAT?
A: Treat the FAT evidence as applying to the version actually tested. Identify which URS requirements and recorded tests the change affects, then decide which evidence must be updated or which functions must be challenged again before accepting the changed version.
Q: What project information should be ready before the SAT protocol is finalized?
A: Define the actual utility conditions, room interfaces, integration points, relevant site conditions, transport-sensitive functions, applicable URS requirements, and project-specific acceptance criteria. This information lets the SAT scope target conditions the supplier-site setup could not represent.
Q: Does successful FAT and SAT evidence mean the isolator is ready for operational use?
A: No. FAT and SAT establish evidence for their approved test scopes, but readiness for IQ, OQ, PQ, or operational use depends on the project’s release criteria. Before advancing, confirm that required records are present, the applicable URS requirements are traceable, and deviations affecting that release decision have documented closure.
