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. Every transition stamps current_step; optional from: lists enforce which prior steps may advance.

Use sagas when:

You need to gate actions on current process step (preflight checks entity._tmp.<saga>.current_step)
The process has a clear terminal state
All state for the process lives on one entity

Naming note: Runtime reliability compensation (reliability.compensating_intent on actions) is a separate multi-entity abort path — not the sagas: DSL macro. See Defining Sagas → Runtime reliability.

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 Temporal-style workflow replay or activity worker
No automatic undo of DSL saga steps on failure — model domain compensation with explicit actions (or use reliability.compensating_intent for coordinated multi-entity abort)
No multi-year sleep timers
No external signal API like Temporal

For long-running orchestration outside the ledger, integrate an external orchestrator that submits intents to Causet.

Sagas vs submit chains

Concern	Saga	Submit chain
Track single-entity progress	Yes	No
Fan out across entities	No	Yes
Gate on process state	Yes	Possible
Parallel steps	No	Yes
Terminal state	Yes	No

Most production flows combine both.

Sagas vs distributed workflow engines

	Causet saga	Distributed workflow (e.g. Temporal)
Scope	Single entity	Multiple services
State storage	Entity `_tmp/` snapshot	External workflow history
Coordination	Event-driven within entity	Orchestrator commands
Replay	Fully replayable with ledger	Engine-dependent
I/O in steps	None — emit events instead	Built-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

Defining Sagas — syntax
Examples — ticket import and purchase flows
Steps — submit chains and transitions

Overview Defining Sagas