Mode Attribute
The mode attribute is the ISA-88 setting on every procedural element — phase, operation, unit procedure, equipment module, unit — that determines who or what can drive state transitions: Automatic, Semi-Automatic, Manual or Out-of-Service. Mode is a first-class attribute because the same recipe behaves very differently in each mode, and audit, validation and operator UX all hinge on knowing what mode the work ran in.
01The four standard modes
- Automatic — recipe sequences phases and transitions; operator can Hold/Abort but cannot bypass logic.
- Semi-Automatic — recipe sequences but each transition requires operator confirmation; common for training, qualification, new-product transfer.
- Manual — operator drives phases and transitions; recipe is informational, not commanding. The system still tracks state but does not advance it.
- Out-of-Service — element cannot execute regardless of command; used for maintenance, calibration, decommissioning.
Some vendors add intermediate modes (Single-Step, Engineering, Maintenance). These are useful but should map cleanly onto the four standards for audit and portability.
02Why mode matters
- Audit clarity — reviewers must know whether transitions were system-driven or operator-driven; mode is the answer.
- Validation scope — PPQ and OQ are typically performed in Automatic mode; runs in other modes do not count.
- Operator authority — Manual mode requires elevated training and authorisation; the system enforces this through role-based access.
- Deviation triggering — a switch from Auto to Manual mid-batch is a deviation event by policy, regardless of intent.
- Trend analysis — batches run in different modes belong in different cohorts; aggregate KPIs are misleading otherwise.
03Mode hierarchy and inheritance
Mode applies at multiple levels of the procedural model. Sane defaults:
- A unit procedure in Manual mode forces its operations and phases into Manual unless explicitly overridden.
- A unit in Out-of-Service mode forces every procedural element targeting it into Out-of-Service.
- Equipment-module mode (set by maintenance) can override procedural-element mode when in conflict — the equipment is unavailable.
- Mode changes propagate downward at the moment of change; child elements already in different modes are reconciled with documented rules.
The inheritance model needs to be one-sentence describable. If operators or engineers cannot explain it consistently, mode changes will create incidents.
04Permissions for mode change
- Automatic → Semi-Auto — typically operator with reason code; logged.
- Semi-Auto → Manual — supervisor required; reason code mandatory; deviation event raised.
- Manual → Automatic — supervisor confirms equipment state synchronised with recipe expectation before allowing.
- Any → Out-of-Service — maintenance role; equipment is locked out for the duration.
- Out-of-Service → any — requires equipment state machine to confirm calibration, clean, PM all valid.
Permissions are enforced through role-based access controls; the action is logged with actor, prior mode, new mode, reason and timestamp.
05Operator experience
Mode must be unmistakable on the operator HMI:
- Persistent mode badge per unit and per phase, with color coding (green Auto, amber Semi, red Manual, grey OOS).
- Mode-change confirmation dialog with mandatory reason code from a controlled list.
- Audit-trail entry for every mode change visible directly from the kiosk.
- Visual differentiation of commands available per mode — Auto shows only Hold/Abort; Manual exposes per-phase command palette.
- Shift handover summary shows current mode per unit and any mid-batch mode changes during the shift.
06Cross-industry examples
- Pharma — PPQ batches in Auto; tech-transfer training batches in Semi-Auto; troubleshooting after a deviation may go to Manual.
- Biopharma — most production in Auto; commissioning new bioreactor in Semi-Auto; sterilisation cycle re-validation may temporarily set unit OOS.
- Food — packaging line in Auto; product changeover may briefly use Manual for line-clearance verification phases.
- Cosmetics — bench-to-pilot scale-up batches in Semi-Auto with operator confirmation per phase for data collection.
- Chemicals — campaign manufacturing in Auto with parametric release; investigational batches in Semi-Auto with additional sampling.
07Common mistakes
- Running production in Semi-Auto by default because Auto is 'too risky' — defeats automation, creates training burden, audit risk.
- Manual-mode operations not deviation-flagged — runs are released alongside Auto batches in trend analysis.
- Mode-change reason codes left as free text — analytics impossible, audit weak.
- Out-of-Service overridden by privilege escalation rather than re-qualification — equipment used unsafely.
- Mode-inheritance rules undocumented — children in unexpected modes; surprise incidents.
- No persistent visible mode indicator — operators unsure what mode they are in; commands behave unexpectedly.
08How V5 Ultimate handles mode
Frequently asked questions
Q.Can a batch be released if it ran in Manual mode?+
Yes, but with elevated review — every phase was operator-driven, so review-by-exception cannot apply. Full per-phase review is required, with attention to the Manual entry rationale.
Q.What is the difference between Semi-Auto and 'paused Auto'?+
Semi-Auto requires operator confirmation at every defined transition; paused Auto is a Hold state in Auto mode awaiting Restart. Semi-Auto changes the recipe execution pattern; paused Auto suspends it.
Q.Why is Out-of-Service a mode rather than just a status?+
Because it interacts with procedural execution. A unit in OOS rejects every command from any recipe; the model needs to be evaluated by the scheduler and operator UI alike. Treating it as a peer of Auto/Manual gives one consistent evaluation point.
Q.Can I run different units in different modes within the same batch?+
Yes — mode is per element. One unit procedure can run Auto while another runs Semi-Auto during a tech-transfer batch where one unit is well-characterised and the other is being trained on.
Q.How do mode changes affect electronic signatures?+
A mode change is itself a recorded event, signed by the actor. Phase-level signatures (start, end, IPC) continue to be captured per mode; the difference is what the signature attests — Auto attests that the operator was present; Manual attests that the operator drove the transition.
Primary sources
Further reading
V5 Ultimate ships with the Mode Attribute controls already wired in — audit trail, e-signatures, validation evidence. Free trial, no credit card, onboard in days, not months.
