Permissive Condition: Readiness Checks and Control Design

A permissive condition is a condition specified in a control design whose satisfaction allows a command or, when the design specifies maintained evaluation, continued operation. This is an engineering convention, not a universal legal or standards definition. Its meaning depends on the particular command, operating state, and evaluation behavior documented in the design.

In the proposed design, distinguish these checkpoints in the functional requirement specification:

• Condition satisfied: the evaluated input meets its defined rule. Other conditions may still block the command.
• Command accepted: the controller accepts the request under its command-handling logic. Acceptance alone does not establish physical movement or flow.
• Equipment action confirmed: specified feedback indicates that the requested action occurred, such as valve-position feedback confirming an open valve.

Readiness also has different subjects. Equipment readiness might concern a drive being available for control. Process readiness might concern a receiving vessel having capacity for the intended transfer. Quality readiness might concern the material having an approved status for the intended use. These are different facts, supported by different evidence; a ready drive says nothing about material disposition, and an approved material status says nothing about vessel capacity.

A readiness result is not, by itself, a quality-release decision or evidence that a functional-safety requirement has been met. Keep the relevant batch-release decision criteria and safety assessment distinct from the permission to execute a particular operation. The practical question is therefore not simply whether the system is ready, but what it is ready to do and which facts establish that permission.

In common control-engineering usage, these terms describe overlapping functions, not a universal naming system. Compare the evaluated condition, timing and resulting action. Neither permissive nor interlock establishes a recipe-only or safety-only role; an interlock can inhibit or interrupt an action without being safety-rated.

A start-only permissive is checked when accepting the start command; that check alone does not prescribe a response to later loss. A maintained permissive continues to govern operation. Depending on the design, loss may pause a sequence, initiate a controlled stop or remove an operating enable. Specify timing, delays and recovery in the functional requirement specification, rather than inferring them from the label.

For example, assume one source-tank level input serves several functions: adequate level permits pump startup; low level during running raises an alarm; a separately configured low-level response stops the pump through interlock logic. The alarm indicates the abnormal condition; the interlock performs the automatic action. Sharing an input does not make those functions equivalent or independent. The cause-and-effect specification identifies which response applies in each operating state and whether restart needs a new command.

As a control-design practice, name each permissive for the asset, intended action, and expected condition. Transfer pump start: receiving vessel capacity available is more useful than Ready. Keep a stable rule identifier separate from the operator-facing label so wording changes do not break traceability.

• Purpose and ownership: record the engineering reason for the restriction, the authoritative source of its input, and the responsible owner who can resolve questions about the rule.
• Operating scope: identify affected modes and how product, recipe revision, and asset identity select the applicable rule. Link revision-dependent decisions to the relevant recipe supersession history, rather than relying on a recipe name alone.
• Evaluation and loss response: specify whether evaluation occurs at command acceptance, during operation, or both; document reassessment triggers and the intended response when the condition becomes false or its input becomes unusable.
• Comparison semantics: document engineering units, comparison direction, inclusive or exclusive boundaries, and any filtering or hysteresis. Explain whether filtering delays recognition and how separate entry and exit thresholds affect the decision.
• Applicability: make not-applicable status an explicit result of the approved applicability rule. Missing evidence does not establish non-applicability; keep those cases distinguishable.

Record why each gate remains necessary, not merely where its logic originated. This rationale gives reviewers a basis for challenging inherited restrictions and selecting meaningful operational qualification tests. Treat an undocumented inherited gate as a review issue, not as justification for either retaining or deleting it.

Treat readiness as a decision tied to a particular command and operating context, not a permanent equipment attribute. The following is a recommended control-design sequence, not a regulatory definition.

1. Select the rule and acquire inputs. Identify the requested command, active mode, equipment state, and material identity before selecting the applicable rule revision. Acquire observations with their source, timestamp, and status; do not carry a previous context’s permission into the new evaluation.
2. Check validity before evaluating values. Distinguish pass, fail, and unknown. Missing, stale, contradictory, or invalid observations should produce unknown for the affected condition rather than silently becoming pass. Define freshness criteria appropriate to how quickly each input can change.
3. Evaluate and map the result. For this article’s examples, assume an all-required-conditions rule: all conditions passing permits command handling; any failed condition blocks it; otherwise, an unknown condition holds the command pending resolution. This assumed AND rule is not universal. Document the result-to-command mapping for each actual design.
4. Recheck at the execution boundary. A displayed ready state may be older than the command request. Recheck changeable inputs where the command is accepted for execution, commonly in the PLC. If execution is queued, validate again before dispatch. Permission alone does not establish that equipment acted.
5. Consume permission and monitor as applicable. Specify whether command acceptance consumes a one-use permission. Define which mode changes, material changes, and equipment-state transitions invalidate cached readiness and trigger fresh evaluation. Apply the monitoring behavior described in the permissive-versus-interlock comparison rather than assuming every condition has the same operating role.
6. Recover through reassessment. After the blocking cause is resolved, acquire valid inputs and evaluate the current context again. Define whether a fresh command or acknowledgement is needed; restored readiness should not imply automatic restart. Route unexplained or recurring failures through the appropriate deviation or nonconformance process.

As a control-design practice, give each blocked action a diagnostic view: action requested, unmet condition, relevant source or instrument tag, evaluation time, and responsible role. Keep these details beside the status rather than behind a generic Not ready indicator. Identify who can investigate, who can decide, and what the operator is authorised to do.

Distinguish the following states in words, not colour alone. Illustrative messages—not product messages—include:

• Unsatisfied: Transfer blocked; lot disposition pending. Request a quality decision from the authorised quality role.
• Invalid data: Pump start blocked; pressure input stale. Ask the authorised technician to check the instrument and signal path.
• Evaluating: Start request awaiting readiness evaluation. Wait for the result; escalate an overdue evaluation under the operating procedure.
• Inapplicable: Rule excluded for the selected operating mode. Show the applicability reason; escalate a mode/configuration conflict to the controls owner.

At the checkpoints covered above, display command acknowledgement separately from actual equipment feedback. Controller accepted request and Motor running feedback unavailable describe different facts; avoid collapsing them into Running.

For investigation, retain the earliest recorded change with surrounding observations and operator actions using attributable recording. Refer to the distinct source, receipt, and evaluation times defined in the data model to account for clock uncertainty. Event order remains an investigative lead rather than proven causation; use root cause analysis before assigning cause.

A practical evidence model links each permissive decision to what the system knew at that moment. Treat the accompanying diagram as an illustrative design model: its entities and field names do not identify a particular application or prescribe a database schema.

Preserve the referenced rule revision and observations, not merely pointers to mutable current values. Otherwise, replaying yesterday’s decision against today’s configuration can produce a different answer. Link the decision to batch execution history where batch context applies.

Keep source observation time, receiving-system time, and evaluation time distinct. Record known clock uncertainty when it could change the interpretation of event order or input freshness; clock drift monitoring supports that assessment. Arrival order alone does not establish process order.

Preserve decision-relevant changes, including validity changes and transitions into or out of permission, in a linked process event log. Select capture frequency and retention for the process and investigation needs rather than imposing a universal interval. A later successful reassessment should remain distinguishable from the original blocked decision.

These illustrative control designs use assumed operating policies, not regulatory acceptance limits. Independent protective functions remain effective throughout. Each case separates the input state, permission decision, and equipment response.

Pharmaceutical batch transfer

• Assumptions: A start-only transfer gate requires acceptable equipment-cleanliness status, matching material identity, and an authorised quality disposition permitting transfer. All other command checks are satisfied. This gate does not define the response to a condition changing during transfer.
• Relevant inputs: Cleanliness = acceptable; material identity = match; quality disposition = hold. Each observation refers to the intended equipment and batch, with its own revision or observation time.
• Evaluation policy: Accept a start request only when all three inputs pass fresh checks. A rejected request is consumed, not queued for later execution.
• Event sequence: The initial request arrives while disposition is hold and is rejected. An authorised person subsequently changes disposition through the QA disposition step. That change alone sends no transfer command. A new request triggers fresh checks.
• Resulting decision: Initial state: transfer blocked, no start issued. Later state: all checks pass, new request accepted and start issued. Equipment feedback, rather than permission alone, establishes whether transfer actually starts.
• Retained evidence: Preserve both request identifiers, input snapshots and timestamps, rule revision, rejection reason, authorised disposition-change record, later acceptance, issued start, and equipment acknowledgement.

Food-process pumping

• Assumptions: The receiving vessel has no concurrent inflow. Its reserved margin accounts for the reviewed process allowances. The volume comparison applies at start; measurement validity remains monitored during pumping. Requested volume and usable headspace are nonnegative.
• Relevant inputs: Vessel capacity C, measured contents M, reserved margin R, and requested volume Q are all in litres. Usable headspace H = C − M − R, also in litres.
• Evaluation policy: With valid, fresh measurements, the inclusive volume comparison passes when Q ≤ H. For this example, set Q = H: equality passes exactly. A stale measurement resolves to unknown, not to a retained valid value.
• Event sequence: Fresh inputs establish Q = H; the start request passes and pumping begins. During pumping, the contents measurement exceeds the design's freshness allowance. Measurement validity changes from valid to unknown.
• Resulting decision: The reviewed response assumed here changes running to controlled stop requested, then to stopped when feedback confirms completion. This response belongs to this example's design; it is not a universal response to stale measurements.
• Retained evidence: Preserve C, M, R, Q, calculated H, units, measurement timestamps, freshness-policy revision, comparison result, validity transition, stop request, and stop confirmation.

Medical-device packaging

• Assumptions: Indexing requires acceptable tooling identity and local drive-ready confirmation. Quality disposition already permits processing and is managed separately.
• Relevant inputs: Tooling identity = acceptable; drive-ready = unsatisfied following disconnection; quality disposition = unchanged.
• Evaluation policy: Reject indexing unless current local checks pass. Reconnection does not authorise replay of an earlier command.
• Event sequence: Reject the initial index request. After reconnection, discard any retained copy of that command. Evaluate a fresh request against current tooling identity and drive-ready status.
• Resulting decision: Indexing remains blocked until the fresh request passes. Then issue indexing; use motion feedback to confirm execution. Neither rejection nor reconnection changes quality disposition.
• Retained evidence: Preserve tooling identity, drive status, connection events, rejected and fresh request identifiers, discard record, decision reasons, issued command, motion feedback, and the unchanged disposition reference.

For pharmaceutical, supplement, food, device, and chemical manufacturers, a useful design-review practice is to assess workplace protection separately from product readiness. A permissive decision is not a substitute for either assessment.

Treat product-specific and non-US obligations as separate applicability questions. For example, review drug manufacturing requirements or food manufacturing requirements for the relevant product context; do not extend the workplace-law and OT-guidance points above into those regimes.

As a control-design practice, assign an authoritative owner for each input: laboratory disposition to the designated laboratory/quality system; material identity to the controlled material-and-lot register; maintenance status to the maintenance system; recipe revision to the controlled recipe repository; and local equipment signals to the equipment controller. Document who resolves disagreements, particularly across maintenance interfaces.

For each upstream interface, specify value meaning, units where applicable, material or equipment identity, source revision, observation time, and validity criteria. In the earlier evidence model, these interfaces contribute observations; the consuming rule produces the readiness decision.

Define handling for delayed updates, duplicate messages, out-of-order events, mismatched identifiers, and conflicting statuses. Typically, consumers enforce freshness limits, deduplicate by event identity, reject older revisions and identity mismatches, and route unresolved conflicts to the designated owner rather than silently selecting a favourable value.

At the consuming controller or workflow boundary, define degraded-operation behaviour: which actions are blocked, which may continue, and under what conditions. On reconnection, reconcile current authoritative state and reassess readiness before accepting pending commands. A successful network exchange establishes neither permission nor command authority.

For manufacturing OT across product types, US NIST SP 800-82 Rev. 3’s Logs are not maintained entry notes that missing or inaccurate logs can prevent determining a security event’s cause and performing adequate forensics. This is guidance, not a product-release rule.

As a control-design practice, establish a firm boundary: design readiness exceptions so they cannot bypass a safety function, machine protection, or lockout/tagout. Keep this boundary explicit in the interlock logic, not merely in an operator instruction.

Define an explicit list of non-safety conditions eligible for exceptions, if any, with an approved alternative for each. Identify conditions that remain non-overridable, including non-safety conditions whose underlying decision cannot be substituted. Absence from the eligible list should mean no exception route.

• Diagnose before escalating: distinguish an actual failed condition from stale data, a failed instrument, or an unavailable status source.
• Route quality disposition to quality, equipment defects to maintenance, logic or design questions to engineering, and permission problems to the access-control owner. Ability to edit a display is not decision authority.
• For a permitted non-safety exception, record the reason, affected equipment or batch, authorisation, compensating measures, and expiry or termination condition. Keep the exception visibly active and retain its approval and removal in the process event log.

Recover by correcting the cause, removing temporary measures under the applicable procedure, and freshly evaluating the normal conditions. Then follow the separately authorised restart sequence; exception closure is not a start command.

Keep actions distinct: acknowledgement records awareness; reset clears a latched state when its reset criteria are met; restart initiates operation through the authorised command sequence. Neither acknowledgement nor reset alone should authorise equipment movement.

Use a practice-based failure-mode review to extend the worked batch-transfer, pumping and packaging cases without repeating their sequences.

In operational qualification, test threshold boundaries, transition timing and recovery—not just initial blocking. Record expected versus observed command handling. For communication loss, test the response specified for the affected operation rather than assuming an immediate stop. On restoration, verify reassessment and the specified restart behavior.

Use this recommended acceptance checklist for each permissive rule. The review packet should identify accountable engineering, operations, quality, and safety roles appropriate to the installation, with named owners for unresolved decisions.

• Intended function: confirm the command or maintained operation governed by the rule.
• Source ownership: identify who owns each input and authorises its use.
• Applicability: confirm equipment, operating modes, and recipe relationships.
• Evaluation timing: confirm when readiness is assessed and reassessed.
• Loss response: confirm the specified response to a failed or unavailable condition.
• Operator explanation: check that displayed causes and next actions match implemented behaviour.
• Evidence: reconcile documentation with implemented logic; use an acceptance-test traceability matrix tied to the approved rule revision.
• Exception handling: confirm authority, boundaries, expiry, and recording of permitted non-safety exceptions.
• Recovery: confirm restoration criteria and refer to the earlier test cases for invalid inputs, communication loss, revision changes, and restart behaviour.

Check configuration-change authorisation through change control. Leave unresolved safety or product-quality decisions with the responsible people; a software readiness result does not approve them. Reopen the review after a changed recipe relationship, replacement instrument, controller revision, interface change, or newly identified failure mode.