Why a Workflow Should Move One Step at a Time

A workflow usually becomes difficult at the point where it cannot finish in one request. It calls an external service, waits for a human decision, receives an event later, or needs to recover after a restart. The code is still a sequence of familiar operations, but the sequence has acquired time.

Pravah approaches that problem as a typed graph. A flow advances by one bounded next() step. After that step, its state can be inspected, stored, retried, or resumed. The boundary is intentional: it is a point where the runtime can tell the truth about what has happened and what should happen next.

A small step is a useful checkpoint

The point of a bounded step is not to make every workflow tiny. It is to avoid an opaque block of work that is difficult to observe once it has started. A flow can move, stop, and expose a useful snapshot before the next transition begins.

That gives operators and application code a practical handle on long-lived work. A failure can be attached to a particular step. A retry can be deliberate. A persisted snapshot has a clear meaning rather than being an incidental by-product of a large async function.

The graph and its runtime have different jobs

Pravah separates serializable graph state from the runtime registry that knows how to execute node handlers. That split keeps stored state portable and inspectable while allowing code to provide the behaviour behind each node.

Pravah is not a queue, a scheduler, or a persistence system by itself. Those pieces can sit around a flow when they are needed. Its narrower job is to give a workflow a dependable execution model: typed edges, explicit state, and one step at a time.

That restraint is what makes the model appealing. A workflow engine should make time and failure easier to see, not introduce another place for them to hide.