Operation lifecycle

A request starts as a canonical operation. Policy admission decides: rejected, waiting for approval, or accepted into protocol execution. Once accepted, the DVM records execution status and makes remote waits, local failures, terminal results, and publication visible as distinct states.

Executed and Published are separate states. Executed means the cryptographic computation reached a controlled local result. Published means a separate gate authorized disclosure in a named scope. Clients, audit systems, and support tools share one vocabulary for where an operation is and which control boundary is responsible for moving it forward.

• GET /v1/operations/{operation_id}/lifecycle — compact phase and next-action projection.
• GET /v1/operations/{operation_id}/evidence — record, ledger, journal, and lifecycle proof handles.

Nonces, presign material, and witness-bearing local objects have their own sub-lifecycle: created, reserved, held while peers are pending, finalized, aborted, or poisoned after a conflict. That journal is what lets the system recover after crashes and still detect replay or reuse. A consumed handle leaks only a lifecycle tag — created, reserved, consumed, poisoned — not the underlying material.

When a step fails, the system commits Failed(evidence_cid) before attempting any recovery path. That immutable record makes artifact state unambiguous after a crash: the lifecycle journal records where each piece of one-time material ended up, and the evidence record names why.

PendingRemote is a normal state because threshold signing is a distributed system. Backpressure, delayed mobile participants, HSM queues, and delivery gaps are handled as protocol state rather than errors. A failed operation carries a reason code and an evidence boundary, giving SDKs enough information to decide whether to poll, retry, prompt for approval, escalate, or show a terminal receipt.