Permissive Condition

A permissive is a recipe-layer boolean: it must evaluate true at the moment a step is commanded to start. If the boolean is false, the command is refused and the recipe holds at the permissive until the condition becomes true, the timeout expires, or the operator routes to an exception path.

• Equipment-state permissives — unit clean, calibration current, PM not overdue, no active interlocks.
• Material permissives — required lots reserved, dispense weights within tolerance, expiry not exceeded.
• Procedural permissives — previous operation complete, sample taken, line-clearance recorded.
• Signature permissives — supervisor sign-off, second-witness verification, QA disposition.
• Compound permissives — boolean combinations of the above (AND/OR with explicit precedence).

Both gate actions but they sit at different layers and have different semantics. The clean separation matters for audit and validation:

• Every permissive has a stable name visible in the eBR — "PrevOperationComplete", "UnitClean", "LineClearanceSigned".
• Every permissive carries a rationale — why this check exists and what risk it mitigates.
• Permissive expressions are typed and validated at recipe approval — boolean over typed inputs, not free-text formulas.
• Compound permissives state their precedence explicitly — '(UnitClean AND CalibrationCurrent) OR EngineerOverride' is unambiguous.
• Naming is governed by a controlled vocabulary so cross-recipe analytics works.

Permissive design lives or dies at the operator kiosk. The good pattern:

1. Operator commands phase start.
2. System evaluates all permissives; if any false, displays a list of which conditions are not met and what is needed.
3. Operator addresses each (signs off, awaits cleaning verification, etc.); list re-evaluates live.
4. When all green, command proceeds.
5. If timeout expires before all green, system raises an exception with the unmet permissives logged.

The bad pattern — generic 'cannot start, check conditions' message — wastes operator time and trains them to call engineering on every phase.

Permissives that cannot be met within the timeout escalate to the exception path. Typical routes:

• Supervisor override — privileged user can authorise start despite unmet permissive, with mandatory justification recorded.
• Hold-for-investigation — phase holds; engineering investigates underlying cause; eBR captures the time and decision.
• Abort — recipe terminates the unit procedure; batch disposition follows.
• Reroute — recipe takes the alternative branch designed for this case.

• Pharma — dispense permissive checks: scale calibration current, materials within expiry, BOM matched, dispense booth differential pressure within range, operator trained and certified.
• Biopharma — bioreactor inoculation permissive: column-clean status, media-prep complete and within hold time, transfer-line CIP/SIP within validation window, inoculum viability test passed.
• Food — fill permissive: line-clearance completed and signed, pasteurisation log within parameters, primary packaging lot reserved, allergen change-over verified.
• Cosmetics — emulsification permissive: oil and water phases both at correct temperature, vacuum integrity verified, agitator calibration current.
• Chemicals — reaction permissive: feedstock totes verified, nitrogen blanket established, cooling utility available, emergency vent path clear.

• Permissive logic baked into phase code rather than declared at recipe level — invisible to reviewers.
• Free-text permissive conditions — ambiguity at runtime, no analytics possible.
• No timeout — phases hang indefinitely waiting on a permissive that will never clear.
• Override workflow without rationale capture — audit trail useless.
• Permissive list grows with every recipe — no controlled vocabulary, every recipe invents its own names.
• Operator UI shows only a generic 'cannot start' message — operators stop trusting the system.
• Equipment-state permissives (clean, calibrated) recomputed locally per recipe — divergence with the equipment-state machine.