After the plant connection returns, is the order still in the right state?

Assume the MES owns the quality hold for the order, while ERP owns its planning information. The interface distributes updates between them. For this evaluation, a hold remains effective until an authorized newer quality decision removes it. An older release event must not override that decision simply because it arrives later.

These state ownership assumptions must be checked against the actual ERP and MES contracts. The plant team must supply the actual ownership, version and transition rules. Without that agreement, a test can show two different final states but cannot establish which one is correct.

A connectivity check can confirm that messages move again. It does not establish that the receiver applies them in a valid order, recognizes a repeated delivery or preserves a current hold. A normal sequence with one message per transition leaves those questions unanswered.

The release review therefore follows one order through interruption and recovery. It inspects the business state after each relevant event, not just the transport acknowledgment. The key question is whether an old or repeated event can create a transition that the current quality decision forbids.

Use an isolated software environment with synthetic orders and no route that can issue commands to live equipment. Match the relevant interface versions, queue settings and state rules to the intended release. Document any differences in timing, storage or connectivity that could affect recovery.

NIST guidance for operational technology security recognizes the distinct performance, reliability and safety needs of operational systems. Here, that supports a carefully bounded software exercise. It does not make a passing interface test a safety assessment or proof that a production line is ready.

A scoped Zof evaluation would use the System Graph to connect the interface change to order events, the quality decision and the receiving application. Plant engineers confirm that map and identify which relationships matter to the planned update.

The Verification Engine would exercise the agreed interruption, repeat and ordering cases. Select edge execution or deployment on premises only where it fits the approved environment. The test setup must provide the required event controls; the scenario assumes no particular vendor adapter, digital twin or automatic offline buffering feature.

For each case, inspect the order before interruption, the authoritative quality revision, the delivered events and the state after recovery. Record event identity and business version as well as timestamps. Clocks alone cannot establish authority when systems are disconnected or their time differs.

The acceptance condition is that the hold remains effective, order state reconciles under the agreed ownership rules and repeated events do not create an unintended second transition. A contradictory record, missing trace or unexplained state change keeps the case open. Correct transport behavior cannot compensate for incorrect business state.

A test against a different queue policy or consumer version cannot settle the production question. Record those differences in the release review and decide whether another check is necessary. A restart during recovery is a separate condition if it was not exercised in the agreed scope.

For a manufacturing software team, the output is a reproducible recovery record and a list of exceptions the release owner can act on. Measure operational changes such as downtime or throughput separately, against a defined baseline and observation period after deployment.