Real-Time Execution State Machine

This topic is part of the SG Systems Global Guides library for regulated manufacturing teams evaluating MES/QMS/WMS controls.

Updated December 2025 • real-time execution state machine, hard gating, step lifecycle states, hold/release, exceptions, audit trails, training/calibration gating, review by exception • Dietary Supplements (USA)

Real-time execution state machine is the rule-driven model that defines exactly what “state” a batch, step, asset, or task is in at any moment—and what transitions are allowed next. In a regulated supplement plant, this is the difference between a system that records what people say happened and a system that controls what can happen. A state machine turns execution into a governed workflow: steps cannot be skipped, holds block progress, approvals are required for exceptions, and the batch record is built from state transitions rather than after-the-fact data entry.

Buyers searching for real-time execution state machine are usually aiming for “hard-gated execution” and review-by-exception. They want to reduce QA review burden while increasing compliance rigor by ensuring the record is self-evidencing: the system knows which steps were routine, which were exceptions, and why. That requires a clear state model and deterministic transitions with audit-ready evidence.

“If your system doesn’t have a state machine, it isn’t controlling execution. It’s documenting it.”

1) What buyers mean by a real-time execution state machine

Buyers mean: “the system should know what’s happening and control the next move.” A state machine is a deterministic map of what “done” means and what’s required to get there. In manufacturing execution, it prevents the two most common failures:

• Skipping. Steps can be skipped or marked complete without evidence.
• Reconstruction. Steps are “filled in later” because the system didn’t enforce contemporaneous capture.

In a true state machine, you can’t just enter data and call it done. The system transitions through states only when requirements are met.

2) Why state machines matter in regulated manufacturing

Regulated manufacturing is about defensible evidence. A state machine is evidence engineering because it creates a controlled lifecycle:

• Every step has an allowed start condition.
• Every completion requires evidence (scan, weight, checklist, signature).
• Every exception becomes visible and governed.
• Every release requires closure of unresolved states.

That reduces QA review burden because QA is not searching for missing information. The system prevented missing information from being created. This is the enabling layer for hard-gated execution and review-by-exception.

3) What needs a state machine: batch, step, asset, material, task

A common mistake is to build a state machine only for “the batch.” In practice, multiple objects need state:

• Batch/work order: planned → released → executing → complete → QA review → released/closed.
• Step/operation: not-started → ready → in-progress → blocked → complete → verified.
• Material lot: received → quarantine → approved → allocated → consumed → depleted.
• Asset/instrument: available → in use → cleaning required → maintenance → out-of-service.
• Quality events: deviation/OOS/CAPA lifecycle states linked to the batch.

Execution reality emerges from interactions between these state machines. For example, a step can’t enter “ready” if the required asset is out-of-service or if the required material lot is still quarantined.

4) Core state set: the minimum viable lifecycle

Keep the state set small and meaningful. A practical step lifecycle:

Batches and assets have their own state sets, but the principle is the same: states should represent real operational conditions, not vague labels.

5) Allowed transitions: what moves a state forward (and what blocks it)

The power of a state machine is not the states—it’s the allowed transitions and required evidence. Examples:

• Planned → Ready requires: materials allocated and approved, asset eligible, staffing/training eligibility met.
• Ready → In Progress requires: authorized user starts step (role + training gate).
• In Progress → Complete requires: required evidence captured (scan/weight/checklist), tolerances satisfied, no unresolved gate failures.
• In Progress → Blocked occurs when: a gate fails (wrong lot, calibration overdue, missing verification).
• Blocked → In Progress requires: gate resolved (asset corrected, lot corrected, verification completed) or an approved override.
• Exception → Complete/Verified requires: disposition approval (supervisor/QCU) and recorded rationale.

This is how the system prevents “just mark it done.” Marking done becomes a state transition with requirements, not a checkbox.

6) Execution gates: training, calibration, lot status, equipment eligibility

Gates are conditions that must be true before a state transition is allowed. High-payback gates:

• Training gate: only qualified users can start/complete/verify a step (Training-Gated Execution).
• Calibration gate: required instruments must be in calibration (Calibration-Gated Execution).
• Lot status gate: only approved lots can be consumed; quarantine/hold blocks consumption (hold/quarantine).
• Equipment eligibility gate: asset state must be eligible (maintenance, cleaning verified, etc.) (Equipment Execution Eligibility).
• Authority gate: RBAC prevents unauthorized actions (Role-Based Execution Authority).

A state machine without gates is a status tracker. Gates make it a control system.

7) Exception states: deviation, OOS/OOT, holds, and controlled overrides

Exceptions should be first-class states, not hidden notes. When an exception occurs, the state machine should:

• freeze progression (block downstream steps if required)
• create a linked workflow (deviation, OOS, CAPA)
• require disposition decisions and approvals
• capture reason-for-change and evidence attachments

This is how you prevent exception normalization. If exceptions don’t create friction and visibility, they become routine and unreviewed.

8) Concurrency and verification: dual sign-off, independent checks, SoD

Many high-risk steps require independent verification (four-eyes). A state machine supports this by separating “complete” from “verified.” That means:

• operator completes step → state becomes Complete
• independent verifier confirms → state becomes Verified
• downstream steps may require verified status, not just complete

This aligns with Concurrent Operator Controls and segregation of duties: the same user cannot verify their own work for critical steps.

9) Time logic: contemporaneous recording, late entries, and clock-based rules

Real-time state machines are also time-aware. They can enforce:

• contemporaneous capture (timestamps at the moment of execution)
• hold-time windows (WIP cannot sit too long without action)
• late entry handling as an exception state
• deadline-based escalation (e.g., verification must occur within X minutes/hours)

If time is not modeled, “we’ll fill it in later” becomes normal. Time-aware states prevent evidence degradation.

10) State transitions as genealogy: building execution-level evidence

The best part: when state transitions are the primary data, genealogy becomes automatic. Each consumption event, verification, and disposition is a state transition that can be linked into execution-level genealogy. That means:

• genealogy edges are backed by state transition evidence
• substitutions appear as explicit transitions
• rework becomes a separate state-driven node

This is why state machines reduce manual batch review: the record is built by the system as it controls work.

11) Batch closure and release: review-by-exception output

A state machine enables release logic: a batch cannot move to “released” if:

• required steps are not complete/verified
• open deviations/OOS/CAPA exist
• label reconciliation is unresolved
• holds are still active

Instead of QA hunting for missing pieces, the system enforces closure conditions. QA then reviews exceptions: the small set of transitions that were abnormal (overrides, substitutions, retests, corrections). That is the practical definition of Review by Exception.

12) Audit readiness: what the state machine proves automatically

With a real state machine, you can prove:

• the process followed the defined sequence (no skipped steps)
• who performed each action and when
• what gates blocked work and how they were resolved
• what exceptions occurred and how they were dispositioned
• who approved deviations/overrides and why

And because all of this is built as execution occurs, you avoid the audit failure mode of “incomplete records” and “reconstructed narratives.”

13) KPIs: what a state machine enables you to measure

These KPIs aren’t vanity metrics. They tell you where your plant loses time and where your controls are creating friction. Then you optimize workflows without weakening gates.

14) Copy/paste demo script and selection scorecard

Use this to validate that “states” are controls, not labels.

15) Selection pitfalls (how “states” become labels, not controls)

• States editable after the fact. If users can change state without evidence, it’s not a state machine.
• No gating logic. Steps move forward regardless of calibration/training/lot status.
• Exceptions not linked. Deviations/OOS exist elsewhere and don’t block release.
• Skipped verification. “Verified” is optional, not enforced via SoD.
• Audit trails incomplete. You can’t prove who moved the state and why.

16) How this maps to V5 by SG Systems Global

V5 implements hard-gated execution as a real-time state machine across MES/WMS/QMS, so steps, holds, exceptions, and approvals are governed and audit-ready.

• Execution lifecycle: V5 MES
• Status enforcement: V5 WMS
• Exceptions and approvals: V5 QMS
• Integrations: V5 Connect API
• Platform view: V5 solution overview

17) Extended FAQ

Q1. What is a real-time execution state machine?
It’s the rule-driven lifecycle model that controls what state a batch/step is in and what evidence is required to move to the next state.

Q2. Why does it matter for compliance?
Because it prevents skipped steps and after-the-fact reconstruction by enforcing gates and capturing evidence contemporaneously.

Q3. What’s the difference between “status” and “state machine”?
Status is a label. A state machine enforces allowed transitions and required evidence; you can’t move forward without meeting rules.

Q4. How does it enable review by exception?
Routine steps flow through normal states; exceptions create explicit exception states and linked events, producing a clean exception summary for QA.

Q5. What’s the biggest red flag in a vendor demo?
If steps can be marked complete without meeting gates (training/calibration/lot status) or if “verified” can be self-approved.

Related Reading
• Guides: Training-Gated Execution | Calibration-Gated Execution | Equipment Execution Eligibility | Review by Exception
• Governance: Quality Control Unit | 21 CFR 111 QC | Concurrent Operator Controls
• Glossary: Hard Gating | Quarantine/Hold | Audit Trail
• V5 Products: V5 MES | V5 QMS | V5 WMS | V5 Connect API