Phase Class Library

ISA-88 defines a phase as "the lowest level of procedural element in the procedural control model". A phase does one independent thing — Charge water, Heat to setpoint, Hold temperature, Mix at rpm, Sample for IPC, Discharge to next vessel. The phase class is the reusable template; the phase instance is what runs in a specific recipe at a specific time.

• Phase name and unique class ID.
• Required parameters (with types, units, allowable ranges).
• Required equipment capabilities (jacket, agitator, vent valve).
• Pre-conditions (line clear, equipment clean, vessel empty).
• State model implementation (idle → running → complete; held, stopped, aborted).
• Exit conditions (target reached, time elapsed, IPC pass).
• Failure handlers (deviation triggers, automatic hold rules).
• IPC hooks — sampling points that can fire during the phase.

Without a phase class library, every new recipe writes its own version of Charge, Heat, Mix. The result:

• Inconsistent behaviour across recipes — Charge in one recipe pauses for a sample, Charge in another does not.
• Duplicated validation effort — same phase validated independently for every recipe.
• Diverging code in the control system — phase logic implemented differently per programmer.
• Update fan-out — a regulatory or safety change must be applied recipe by recipe.
• Tech transfer fails — sending site's phases do not exist at the receiving site.

A maintained library inverts this: the phase is validated once, used everywhere, and an update propagates through change control to every recipe that uses it.

A well-defined phase class declares:

1. Identity — name, class ID, version, owner, status (Draft/Approved/Obsolete).
2. Parameters — typed, ranged, defaulted. Heat phase: target_temperature (°C, 0–150), ramp_rate (°C/min, 0.1–5), hold_time (min, 0–999).
3. Equipment requirements — capability tags the unit must have (e.g. "jacket-cooling", "variable-speed-agitator").
4. Pre-conditions — checks that must pass before the phase can start (vessel-empty, line-cleared, equipment-clean, operator-trained).
5. Procedural logic — the steps the phase performs (energise jacket, open valve, monitor temperature, end at setpoint).
6. State transitions — how the phase responds to commands (Hold, Stop, Restart, Abort).
7. Exit conditions — what causes the phase to complete normally.
8. Failure conditions — what triggers a deviation or automatic hold.
9. IPC binding — what samples can fire during the phase and at what triggers.
10. Data capture — what is logged to the BMR (setpoint, actual, deviation events, equipment status).

The library is itself a controlled artefact:

• Phase classes are versioned independently of recipes.
• A phase-class revision triggers an impact assessment on every recipe using it.
• Approval workflow is similar to recipe approval — author, reviewer, QA, plus control-system SME and validation.
• Library Owner role (usually MES + control-system engineering jointly) is responsible for keeping the library curated, removing obsolete classes, preventing duplicate "new" classes for things the library already does.
• Annual periodic review per Annex 11 §11.

• Pharma API — common classes: Charge-Solvent, Charge-Solid, Heat-Reflux, React-Hold, Quench, Filter, Wash, Dry, Cool, Discharge, CIP-Pre, CIP-Caustic, CIP-Rinse, SIP.
• Biopharma — Inoculate, Feed, Harvest, Centrifuge, Filter (Dia/Ultra), Hold-2-8C, Buffer-Prep, Sterile-Transfer.
• Food / Beverage — Receive-Ingredient, Hydrate, Mix, Pasteurise, Cool, Homogenise, Fill, Cap, Label.
• Nutraceutical / Supplements — Weigh-Component, Pre-Blend-Minor, Blend-Master, Granulate, Dry-Fluid-Bed, Mill, Compress, Coat, Polish, Package.
• Discrete electronics — Pick-Component, Place-SMT, Reflow, Inspect-AOI, Test-ICT, Pack.

A mature site will have 30–80 phase classes total — enough to assemble most recipes without inventing new phases for new products.

• No library — every recipe re-defines phases inline.
• Library exists but bypassable — recipes can declare "custom" phases that escape governance.
• Phase classes too coarse ("Process") — no reuse possible.
• Phase classes too fine ("Open-Valve-V-201") — equipment-specific, defeats reuse.
• No version control on the library itself — recipes silently inherit new phase behaviour.
• No impact assessment on phase revision — recipes break unannounced.
• Phase logic split between MES (procedural shell) and PLC (real-time logic) with no synchronised versioning.
• Phase-class duplicates accumulate ("Heat", "Heat2", "Heat-Final") — library becomes a graveyard.