Arbitration & Allocation

ISA-88 separates resource definition (units, equipment modules, shared services) from resource use (recipes). Arbitration is the runtime matchmaking; allocation is the resulting reservation. A control recipe declares its needs, the arbitration engine finds compatible available resources, and the allocation is recorded for the duration of the request.

• Resource — any constrained entity: a unit, an equipment module, a shared utility (chilled water, vacuum, nitrogen).
• Capability — what a resource provides ('jacket-cool', 'CIP-ready', 'working-volume ≥ 1000 L').
• Request — what a control recipe needs at a particular moment in its lifecycle.
• Match — the arbitration result; a specific instance satisfying the request.
• Allocation — the reservation, holding the resource for the requestor until released.

Different resources are arbitrated at different lifecycle points:

Arbitrating too early (e.g. units at WO release rather than unit-procedure start) ties up resources unnecessarily and creates scheduling rigidity. Arbitrating too late risks starving an in-flight batch.

The matching algorithm walks the capability vocabulary:

1. Request resolves required capabilities and constraints (working volume range, material compatibility, current state).
2. Engine queries the resource pool of compatible class(es) with current state filters (in-service, clean if required, calibration current).
3. Candidates are scored by configured policy — round-robin, preferred-unit, least-recently-used, or campaign-locked.
4. Highest-scoring candidate is offered; on acceptance, allocation is recorded; on rejection (race with another request), engine retries.
5. If no candidate found within timeout, the requesting phase holds on a 'no compatible resource' exception.

• Concurrent requests — engine serialises; first request wins; second retries with the next-best candidate.
• Priority — high-priority work orders pre-empt low-priority queueing (configured policy, never default).
• Starvation — long-waiting requests escalate priority over time to prevent indefinite blocking.
• Deadlock — engine detects cycles (A waits on B waits on A); raises operations alert and refuses allocation.
• Force-allocation — privileged override available with mandatory rationale; logged as deviation.

Allocation that is not released is the most common arbitration bug. Discipline:

• Every arbitration scope (unit procedure, phase) has explicit release at its end.
• Abandoned batches release allocations on abort or stop.
• Stuck allocations (resource still allocated after the requesting batch ended) surface on dashboards and trigger auto-release after a timeout.
• Maintenance-driven OOS allocation has explicit clear path back to available pool.
• Resource state on release returns to known clean status (or dirty status flagged for CIP) — no ambiguity for the next requestor.

• Every allocation captured with timestamp, requestor (batch/phase), resource, capability set matched and policy applied.
• Force-allocation events flagged for QA review with rationale.
• Resource history reconstructable — which batches used R-201 in Q3, in what order, with what changeover times.
• eBR records the resource bound to each phase, supporting the 21 CFR 211.188 'identification of major equipment' requirement.

• Pharma — multi-product API plant arbitrates jacketed reactors, filter-dryers and chromatography skids across simultaneous batches.
• Biopharma — shared chromatography skid arbitrated phase-by-phase across multiple product programmes.
• Food — shared pasteurisers and fillers arbitrated across SKUs with allergen-changeover gating.
• Cosmetics — shared vacuum-emulsifier arbitrated across emulsion variants with cleaning-strategy-aware sequencing.
• Chemicals — shared utilities (chilled water capacity, nitrogen pressure) arbitrated across exothermic reactions.

• Recipes pinning to specific instances ('R-201') rather than capabilities — defeats arbitration.
• Allocation at WO release instead of unit-procedure start — units tied up for hours before they are needed.
• No release on abort — stuck allocations require manual clearing.
• Force-allocation without rationale capture — audit useless.
• Capability vocabulary inconsistent across resources — matches fail unpredictably.
• Priority policies poorly configured — high-priority work starves routine production or vice versa.
• No dashboard surfacing allocation state — engineers learn about contention from operator complaints.