The short answer

The governed runtime documents asynchronous lifecycle operations backed by a durable store and idempotency ledger. Use these configured paths when lifecycle state must survive restart, and preserve operation identity and input meaning across repeated requests.

A lifecycle command needs a retained outcome

An operator can ask a mission to pause just before the process exits. If the command changes only in-memory state, the next process may not know what was requested or committed.

The governed runtime facade documents restart-safe asynchronous operations for pause, resume, safe stop, recovery and abandonment. Their purpose is to make lifecycle transitions part of the durable operating record, not merely a local control flag.

Configure the store and ledger deliberately

The reference names durableStore and idempotencyLedger as integration requirements for this path. Supplying an asynchronous method call without the intended persistence composition is not evidence of restart safety.

Check the exact exported contracts for the coordinated version. Record which durable implementation the host supplies, how its schema is managed and how operation identity is retained. Avoid substituting an in-memory implementation in a deployment test that claims process continuity.

Do not reinterpret an existing operation

The runtime rejects repetition under an operation identity with a different input digest. This separates a true retry from a changed request that happens to reuse the same key.

For an illustrative safe-stop request, a lost acknowledgement may justify repeating the original operation. It does not justify silently changing its scope. If the operator intends a different transition, represent that intention through the appropriate new operation and current lifecycle checks.

Connect transition records to the mission history

The facade returns content-addressed cycle receipts and advances mission coordinates including predecessor information. The mission lifecycle reference requires causal continuity for changes such as replanning and reassignment.

Use that history to distinguish an operator's requested pause from a recovery triggered by a failure. Both may stop progress temporarily, but they have different causes and conditions for resumption.

Check restart behavior without conflating effect recovery

  • Issue a supported transition through the durable composition.
  • Restart at a controlled point and inspect retained state.
  • Retry with the original operation identity and input.
  • Attempt reuse with a mismatched input.
  • Follow the transition's predecessor and receipt.

The continuity guidance still requires separate revalidation for external effects. A restart-safe pause record does not settle whether a remote operation completed before the pause took effect.

Sources and further reading

Documentation reviewed . Consult the linked documentation for current implementation details.