WorkflowsConcept

Workflows — Concept

Causet workflows coordinate multi-step logic using the same ledger, rules, and events as everything else. There is no separate workflow engine process. Both sagas and submit chains are fully functional today.


Sagas

A saga is a named state machine bound to one entity type. Progress is stored under _tmp/ in the entity snapshot — survives restarts and replays from the ledger.

Use sagas when:

  • You need to gate actions on current process step (preflight checks _tmp/saga_step)
  • The process has a clear terminal state
  • All state for the process lives on one entity

Submit chains

op: submit in side_effects fires a new intent — possibly on a different entity — after the parent commits.

Use submit chains when:

  • Work fans out across entity types
  • Steps are independent auditable intents
  • Parallel processing is acceptable

Scheduled events

op: schedule emits a delayed event or intent from side_effects. Relative delays only — use an external scheduler for cron-style timing.


What Causet workflows are not

  • No built-in compensation / rollback sagas
  • No multi-year sleep timers
  • No external signal API like Temporal

For those needs, integrate an external orchestrator that submits intents to Causet.


Sagas vs submit chains

ConcernSagaSubmit chain
Track single-entity progressYesNo
Fan out across entitiesNoYes
Gate on process stateYesPossible
Parallel stepsNoYes
Terminal stateYesNo

Most production flows combine both.


Sagas vs distributed workflow engines

Causet sagaDistributed workflow (e.g. Temporal)
ScopeSingle entityMultiple services
State storageEntity _tmp/ snapshotExternal workflow history
CoordinationEvent-driven within entityOrchestrator commands
ReplayFully replayable with ledgerEngine-dependent
I/O in stepsNone — emit events insteadBuilt-in activities

Sagas are for multi-step processes on one entity’s lifecycle. For cross-entity coordination, use submit in side_effects or an external orchestrator that submits intents to Causet.


Durability

Saga state lives in the entity snapshot (PostgreSQL). After a runtime restart, the next intent reads the persisted snapshot and resumes from the correct step — no external saga log required.


Next steps