Unit Procedure

ISA-88 organises procedural control as: Procedure → Unit Procedure → Operation → Phase. The unit procedure owns one unit for a contiguous block of time, from acquisition to release. Everything that happens on that unit during the batch belongs to the unit procedure: charging, processing, sampling, transferring, cleaning-in-place.

• Unit acquisition — the arbitration step that reserves a specific unit instance for the procedure.
• Sequence of operations — typically 2–10 operations executed in order, optionally with parallel or selective branches inside.
• Unit release — explicit release back to the available pool when the procedure completes.
• Unit-level deviations — handled at this scope (e.g. "unit had to be swapped mid-batch").
• Unit-level signatures — supervisor sign-off at procedure entry and exit when SOPs require.

The unit-procedure boundary is where many practical concerns converge:

• Scheduling — finite-capacity scheduling treats the unit procedure as the atomic block on a unit's calendar.
• Arbitration — equipment allocation happens at unit-procedure start, not per-phase, so capability matching is coherent for the whole block.
• Genealogy — material lot consumption rolls up cleanly to the unit procedure that consumed it.
• Review-by-exception — a clean unit procedure is reviewable as a block; the reviewer drills into operations only on exception.
• Tech transfer — unit procedures port between sites as units because they encapsulate the unit's complete contribution.

A typical unit procedure has a familiar shape:

1. Acquire unit (with capability requirements).
2. Verify equipment state (clean, calibrated, ready) — pre-procedure interlocks.
3. Sequence of operations (the productive work).
4. Sampling and IPCs at defined operation boundaries.
5. End-of-procedure clean (CIP/SIP if applicable) or transition to next batch.
6. Release unit.

The PFC inside the unit procedure can be linear or richly branched; what matters is the closure: acquire → work → release, never abandoning the unit silently.

Schedulers reason in unit-procedure blocks because that is the level at which equipment is reserved. Implications:

• Estimated duration of the unit procedure (not each phase) is what drives the Gantt — phase-level estimates aggregate up.
• Unit changeover (between batches on the same unit) is the transition between successive unit procedures — clean status drives gating.
• Campaign manufacturing is, in scheduler terms, a series of identical unit procedures with reduced changeover between them.
• Resource conflicts are detected at unit-procedure overlap on the same unit — the scheduler is unaware of phase-level overlap.

• Unit acquisition failed — no compatible unit available within timeout window.
• Equipment-state precondition failed — unit not clean, calibration expired.
• Mid-procedure equipment failure — swap to a compatible unit if recipe allows; otherwise abort.
• Late operation start — schedule slippage cascades; deviation may be informational.
• End-state cleaning failure — unit cannot be released to next batch until disposition.

These deviations are owned at the unit-procedure scope because the unit is the resource being managed. Phase-level deviations roll up but do not necessarily escalate to the unit-procedure level.

• API — Unit Procedures: Charge Reactor → React → Quench → Filter → Wash → Dry. Each on its own unit, synchronised at material transfers.
• OSD pharma — Unit Procedures: High-Shear Granulation (one granulator), Fluid-Bed Drying (one drier), Milling, Final Blend (one blender), Compression (one press), Coating (one coater).
• Biopharma — Unit Procedures: N-2 Bioreactor, N-1 Bioreactor, Production Bioreactor, Harvest, Buffer Hold. Often run in parallel across unit procedures with synchronisation events.
• Food — Unit Procedures: Hot-Mix Tank, Pasteuriser, Cooler, Filler. Linear flow with explicit unit handoffs.
• Cosmetics — Unit Procedures: Oil-Phase Premix, Water-Phase Premix, Vacuum Emulsifier, Hold Tank, Filler. Parallel premix unit procedures, then synchronised emulsification.

• Unit procedure that spans multiple units — breaks the ISA-88 contract, confuses arbitration.
• No explicit acquire/release — units stay reserved past procedure end, blocking the schedule.
• Cleaning logic placed outside the unit procedure that used the unit — clean status drifts.
• Unit-procedure boundaries chosen by file size rather than process logic — review and tech transfer suffer.
• Sampling phases sprinkled across multiple unit procedures — sample IDs lose their unit context.
• Capability requirements declared only at phase level — unit acquisition cannot reason holistically.