Durability and recovery

Run truth

The append-only event log is authoritative. Context, terminal presentation, run lists, and inspection are projections derived from those events. Mutable summary tables may be rebuilt and are not a second source of truth.

Immutable definitions

Every run binds to the exact compiled workflow and module artifacts active at admission. Editing source affects future runs only. Recovery never silently rebinds an existing run to changed files.

Crash policy

If a step or managed effect has a recorded start without a definitive terminal event, a restart does not prove whether an external side effect occurred. WOML fails that ambiguous work closed unless the reviewed capability has a durable proof allowing safe reattachment. Completed derivation is folded again; an external effect is not blindly replayed.

Duplicate trigger policy

Durable trigger identity plus canonical payload determine duplication. The same identity and payload reuse the original run. The same identity with changed payload is an idempotency conflict. Provider acknowledgements occur only after durable admission.

Atomic deployment activation

All supplied files/directories form one deployment. Providers and listeners start behind a closed readiness gate. WOML hashes and rechecks source before it opens admission. Partial startup is closed if a required provider fails or source changes during activation.

Foreground and background

Foreground is recommended under systemd, Docker, and Kubernetes because the supervisor already owns process lifetime. --background is useful for a directly managed workstation or VPS. Both use the same production Rust host and durable semantics.