Manufacturing · The complete guide

Unit Class Library

TL;DR

A unit class library is the catalogue of equipment unit classes — Reactor, Crystalliser, Drier, Tablet Press, Coater, Filler, Capper — that recipes can reference without binding to specific equipment instances. ISA-88.01 §4.4 defines the unit as the major equipment grouping that owns the procedural execution; the unit class is the reusable abstraction above the unit instance. A maintained unit class library is what lets a site recipe say "requires a jacketed reactor 1,000–3,000 L" rather than "requires Reactor R-201" — preserving recipe portability and equipment-train flexibility.

Reviewed June 3, 2026· By V5 Ultimate compliance team· 2,300 words · ~11 min read

01What a unit class library is

ISA-88's physical model goes: Enterprise → Site → Area → Process Cell → Unit → Equipment Module → Control Module. The unit is the major equipment that holds the procedural execution — it's where a phase runs. A unit class describes a family of units that share capabilities; specific unit instances are members of a class.

Class name and unique class ID — "JacketedReactor-Glass", "FluidBedDrier", "TabletPress-RotaryStation".
Capability tags — what the class can do ("jacket-heat", "jacket-cool", "agitator-variable-speed", "vent-filter", "CIP-spray-ball").
Allowable parameter ranges — working volume (e.g. 500–3000 L), temperature (e.g. -10 to +120 °C), pressure rating, agitator rpm.
Default cleaning programme — which CIP/SIP phase class applies.
Material-compatibility tags — "316L stainless", "glass-lined", "PTFE-wetted".
Qualification requirements — what IQ/OQ/PQ evidence is needed for each instance.

02Why the library matters

Without a unit class library, recipes pin to specific unit instances ("Reactor R-201"). Consequences:

Tech transfer is painful — the new site does not have R-201.
Capacity planning is rigid — only R-201 can run the recipe even if R-202 is available.
Equipment changes (replace R-201 with R-201A) require recipe revision across all affected recipes.
Multi-site recipe management is impossible — every site has different equipment names.

With a unit class library, recipes reference the class; instances are allocated at control-recipe generation. Equipment swaps, capacity shifts and tech transfers become operational rather than recipe-revision events.

03Capabilities vs instances

The capability tag is the matching language. A phase declares the capabilities it needs (e.g. "jacket-heat", "agitator-variable-speed", "working-volume ≥ 1000 L"); a unit class declares the capabilities it provides; a unit instance inherits its class's capabilities plus any instance-specific overrides (e.g. "out-of-service").

At control-recipe generation, the equipment-arbitration step matches phase capability requirements against available unit instances of compatible classes. The richer the capability vocabulary, the more precisely arbitration can work.

04Qualification linkage

Each unit instance is qualified individually (IQ/OQ/PQ per Annex 15), but the qualification protocol is templated from the unit class:

Class defines the IQ scope — installation, utility connections, documentation.
Class defines the OQ scope — operational ranges to challenge, alarms to verify, interlocks to test.
Class defines the PQ scope — performance with representative product, reproducibility.
Instance carries the executed qualification evidence — which protocols passed, when, by whom.
Re-qualification triggers (calibration drift, major maintenance, software update) are class-defined, instance-tracked.

05Library governance

The unit class library is a controlled artefact:

Class definitions are versioned; revisions trigger impact assessment on instances.
Adding capabilities to a class typically requires re-qualification or at least a delta OQ on every instance.
Library Owner role — usually engineering / facilities, with MES + QA review.
Periodic review per Annex 11 to retire obsolete classes and prevent duplicates.
Naming convention enforced — no "Reactor-NEW", "Reactor2" sprawl.

06Cross-industry examples

API manufacture — JacketedReactor-Glass, JacketedReactor-Hastelloy, Crystalliser, FilterDryer-NutscheDryer, FilterDryer-Agitated, RotaryEvaporator.
OSD pharma — Blender-Vbender, Blender-Bin, Granulator-HighShear, FluidBedDrier, Mill-CoMill, TabletPress-RotaryStation, Coater-Perforated.
Biopharma — Bioreactor-Stirred, Bioreactor-WaveBag, Centrifuge-DiskStack, Filter-Crossflow, ChromatographySkid, BufferTank-Hygienic.
Food / beverage — MixingTank-Hygienic, Pasteuriser-HTST, Homogeniser, Filler-Rotary, Capper, Labeler, BlowMoulder.
Cosmetics — Emulsifier-VacuumKettle, Premix-Tank, FillingLine-Tube, FillingLine-Bottle, Cartoner, Caser.

07Common mistakes

Single-instance classes — every reactor is its own class, defeating reuse.
Classes named after vendors ("GEA-Niro-Drier") rather than capability ("FluidBedDrier") — vendor swap requires recipe revision.
Capability tags free-text — typos prevent capability matching at arbitration.
No version control — class capability changes silently propagate.
Instance attributes diverge from class — instance has capabilities the class did not declare; arbitration broken.
Qualification evidence not linked to class — re-qualification trigger not enforced.
Library duplicate classes ("Reactor", "ReactorNew", "ReactorRevised") — library becomes a junk drawer.

08How V5 Ultimate handles unit class libraries

Unit library in V5

V5 implements the unit class library as the canonical equipment vocabulary, with a controlled capability taxonomy that prevents free-text drift. Classes declare capabilities, parameter ranges and qualification templates; instances inherit from classes and carry their executed IQ/OQ/PQ evidence with calibration currency, clean status and PM schedule. Capability matching at control-recipe generation is automatic — the phase declares what it needs, the arbitration engine finds available instances of compatible classes, the BMR captures both the class and the instance allocated. Class revisions trigger impact assessment on every instance plus the descendant recipes; capability additions enforce delta-OQ before any instance is allowed to expose the new capability. Naming convention is enforced through library governance — new classes require Library Owner approval to prevent duplicates and obsolete classes are retired rather than left to accumulate. Multi-site tenants share corporate-level class definitions while keeping site-specific instances, making tech transfer and capacity rebalancing operational rather than recipe-rewrite events.

Frequently asked questions

Q.How granular should unit classes be?+

Granular enough that two instances of the same class are functionally interchangeable for recipe purposes. Two glass-lined reactors with the same working-volume range and capabilities can share a class; a glass-lined reactor and a Hastelloy reactor should be separate classes because their material compatibility differs.

Q.Can a unit instance belong to multiple classes?+

ISA-88 strictly says one class. In practice, capability tags handle the multi-trait reality — a reactor of class "JacketedReactor-Glass" might carry capability tags "CIP-ready" and "high-vacuum" that not every member of the class has. Recipes match on capabilities, not class membership.

Q.How does this relate to the equipment master in the ERP?+

The ERP carries the asset-management view (financial, maintenance, depreciation). The unit class library carries the procedural-control view (capabilities, qualification, recipe compatibility). They share the instance identity but serve different consumers. V5 keeps them synchronised via the standard equipment-master integration.

Q.What happens when a unit is taken out of service?+

The instance's status flips to Out-of-Service in the equipment state machine. Capability matching at arbitration excludes the instance. Recipes that depend on the class continue running on other instances. If the class drops below capacity, work-order scheduling holds new releases until availability returns.

Q.Do I need a unit class library even for single-line, single-site operations?+

Honestly, less critical — a single-instance class adds overhead. But even single-site sites grow, add lines, install a backup, or replace equipment. Starting with the library discipline avoids retrofitting it later when the cost is much higher.