Skip to main content
Version: 0.1.0-alpha.5 (alpha)

Activation commit protocol

This is the planned contract for guest state and effects. The current stateless lifecycle performs execution, cleanup and terminal publication without a durable state/effect commit coordinator. Catalog operation receipts and the audit journal do not implement the guest transaction or recovery protocol below. Durable workflow continuation remains planned work in the roadmap.

The commit coordinator is the semantic boundary between guest completion and externally durable success.

Inputs​

An activation commit plan contains:

  • activation identity,
  • optional state transaction,
  • zero or more effect intents,
  • output digest or result metadata,
  • audit and trace metadata.

Required behavior​

PREPARING_COMMIT
  → validate transaction read set
  → persist state mutations and effect outbox records atomically
  → create durable commit receipt
  → COMMITTED

If the selected backend cannot atomically persist state and effect intents, the deployment must opt into weaker semantics explicitly or use a coordinator/backend combination that can.

Recovery​

Commit inspection by activation ID must distinguish unknown, preparing, committed, aborted, and recovery-required states. A lost client response after commit is resolved by inspection rather than blind re-execution.

Output visibility​

The invocation response may be returned only after the platform has reached the contractually promised commit level. Deferred external effects may still be pending after a successful response, but their intents are durable.