One Source, Three Durability Tiers: How Noorle's Program Runtime Is Built

Note: where this post says “one-off procedure,” read unpublished Program run — not a Procedure object.

Not all durable state is the same shape, and treating it as if it were is either wasteful or insufficient.

A well-built orchestration runtime doesn’t pick one durability mechanism and apply it everywhere. It keeps a single authored source of truth and derives every other view from that source. It sizes the durability guarantee to the structural property of the state it is wrapping — a known set of phases gets a checkpoint; arbitrary control flow gets replay; a run that is allowed to vanish gets neither. And it keeps language execution behind a host boundary so the execution engine never gets to choose any of those things.

That is how Noorle’s Program runtime is built.

One canonical source

The only artifact anyone authors is Program source. Every other representation is compiled from that one parse, hashed, and pinned to it:

• the effect manifest — authority: what this program is allowed to touch
• the control-flow topology — a language-neutral graph projection for review
• the execution outline — a flat phase and call-site list

A derived view can be unavailable or stale. It cannot invent structure it isn’t sure of. An unsupported construct becomes an explicit, flagged region — an opaque block in the topology, a caveat in the coverage report — never a guess rendered as if it were certain.

That is the rule that keeps convenience views honest. A projection is safe exactly as long as it cannot become a second place where the “real” definition quietly lives. The moment a reviewer can edit the graph, or a recovery path can trust a reconstructed outline over the source that produced it, you have two canonical forms. We don’t.

One authoring surface, two execution profiles

A Program runs transient or durable. Transient is bounded, in-process, run-to-completion: the invocation either finishes or fails, and a process death ends it. Durable survives process death, waits, and approvals. The profile is selected per invocation — a one-off procedure picks transient; a published Workflow run picks durable — not by switching products or languages.

The compiled artifact is the same either way. Compilation is profile-aware (the durable profile rejects constructs that aren’t replay-safe; the transient profile rejects waits that would leave a suspended run after the process is gone), but it is one front end and one artifact envelope. The profile changes the durability guarantee that wraps the run, not what was authored and not how it is validated.

Durability sized to the shape of the state

Durability here is a spectrum, not a maturity ranking. Two live tiers sit above a “none” baseline. Each is matched to a concrete structural property of the state it owns.

No durability. A transient run completes or fails. Nothing survives a restart. That is correct, because nothing at this tier is a commitment that needs to outlive a process. The run record and journal still give you an audit trail; they do not make the execution itself durable. A retry is a new run, started from the entry point.

Checkpoint-based durability. Appropriate when a run’s resumable points are few, known, and enumerable in advance — a bounded set of continuation phases. The source of truth is an append-only durable log. At each defined phase the runtime writes a lightweight snapshot; recovery resumes from that snapshot directly, with no re-execution of the work that produced it. This is the job an embedded log-structured storage engine is built for. Noorle uses SlateDB; RocksDB is the well-known ancestor of that design. SlateDB is that model built on object storage.

Replay-based durability. Necessary when control flow is arbitrary and user- or agent-composed, so there is no fixed set of resumable points to enumerate. The run can pause anywhere — inside a nested loop, on one arm of a branch, at a parallel join, on an approval, on a timer. Nothing is snapshotted. Recovery re-executes the deterministic driver from the entry point and replays memoized results for effects that have already completed. Language VM state is never serialized; correctness never depends on a live process. This is what a workflow-orchestration engine is for. Noorle uses Restate; Temporal is the other well-known engine built around the same replay contract.

The comparison is the design:

Enumerable phases → checkpoint. Arbitrary control flow → replay. The runtime does not default to the more powerful mechanism.

The boundary is explicit

Each subsystem’s durability tier is chosen from the actual shape of the state it owns, and that choice is visible. It is not “whichever mechanism happened to be available.”

Getting it wrong costs in either direction. Applying replay-grade machinery to state that doesn’t need it — a run whose cursor, message list, and in-flight calls are already explicit and serializable — pays real latency and infrastructure cost for no correctness benefit. Applying checkpoint-grade machinery to state with unenumerable resumable points is a correctness bug waiting for the right crash: you will eventually pause somewhere that has no snapshot, and resume will not know where you were.

A host boundary that keeps language and durability independent

Programs talk to the outside world through a versioned, language-neutral host API. Inputs, outputs, and effect records are schemas, not language-native values. Agents, capabilities, knowledge queries, child workflows, clocks, IDs, sleeps, and signal waits all cross that boundary as typed host operations.

The replay and checkpoint machinery lives entirely at that host-effect boundary, not inside whatever engine executes the program’s control flow. Durability does not know or care what language produced the call. A completed effect is a memoized host result keyed by a stable call site; a parked wait is a host primitive. The guest is torn down while parked and respawned from the entry point on wake. The language runtime is an execution engine, not a durability participant.

Reviewability without a second canonical format

Because the topology projection is derived and honest by construction, a durable Program’s control flow is always inspectable. Reviewers get a language-neutral graph — sequence, decisions, loops, proven joins, explicit opaque regions — without being asked to trust raw source blindly, and without resurrecting a hand-editable graph as a second execution path. If the compiler cannot represent a region safely, the region is flagged. The source remains the only thing that runs.

Takeaways

• Keep exactly one authored canonical form. Derive every other view from it, and make the derivation fail closed rather than guess.
• Categorize state by how enumerable its resumable points are before picking a durability mechanism — checkpoint for a known phase set, replay for arbitrary control flow. Don’t default to the most powerful mechanism everywhere.
• Push language and execution choice behind a schema’d host boundary so durability strategy and language choice can vary independently.
• For calibration, the two live tiers map to recognizable categories: replay-oriented orchestration (Restate, Temporal) and durable log-structured storage (SlateDB, RocksDB). Pick the shape that matches your state, not the brand.

If you want to see Programs and Workflows on this runtime, look at the platform or start with the docs.