Skip to content

Workflow-Model Compiler

Model compiler — instantiates Specification-to-Execution Lowering

Compiles a process model — a diagram of tasks, decisions, and flows — into an executable orchestration, wiring in the failure handling, compensation, and versioning a long-running process needs but the diagram omits.

A process model — a BPMN diagram, a state machine, a flowchart of "first do this, then if approved do that" — describes a business process at the level a domain expert can draw. A Workflow-Model Compiler lowers that picture into an executable orchestration a workflow engine can actually run: each task becomes a callable step with an interface, each gateway a branch, each flow a transition, plus the machinery a running process needs that the diagram leaves out — what happens when a step fails, how work already done is undone, how a long-running instance survives a change to the model. Its defining concern, and what separates it from a code generator that emits static structure, is time and failure: real processes run for days across unreliable services, so the compiler's distinctive job is turning a happy-path drawing into something that behaves correctly when a step fails midway and must be compensated.

Example

An order-fulfillment process is drawn in BPMN: reserve inventory → charge payment → ship → notify. As a diagram it is four boxes and three arrows. Compiled onto a workflow engine it becomes a durable orchestration: each box a step with a typed interface to its service (inputs, outputs, timeout, retry policy) and — crucially — a compensation path for each, because a process that has charged a card and then cannot ship must not simply error out. The compiler wires the saga: if shipping fails after payment, it triggers the compensating refund and releases the inventory reservation, unwinding completed steps in reverse.[1] It also emits a manual-fallback route — a reservation that fails past its retry budget parks the instance in a queue for a human rather than dropping the order. And because an instance may run for days, the compiler stamps each with the model version it started under, so a mid-flight change to the process does not corrupt orders already moving through the old one. The domain expert maintains the diagram; the compiler turns each revision into a deployable, failure-aware orchestration.

How it works

  • Decompose the model into steps and obligations. Each task becomes a unit of work with an interface and a contract for what it must accomplish; gateways become branch logic, flows become transitions.
  • Wire failure and compensation. For each step, generate retry, timeout, compensation (how to undo it), and a fallback route — the behaviour a diagram leaves implicit.
  • Emit a durable orchestration. Produce the engine artifact that persists instance state across failures and restarts, not a stateless script.
  • Bind versioning and feedback. Pin running instances to their model version, and route runtime signals (stuck steps, repeated failures) back as triggers to revise and recompile the model.

Tuning parameters

  • Compensation completeness — compensate every step vs. only the externally-visible ones. Full compensation makes any failure cleanly reversible but demands an undo for each step; partial is cheaper and leaves some failures needing manual repair.
  • Failure-routing policy — how many retries before failing vs. park-for-human. Aggressive retries mask transient faults but delay real escalation; early human routing is safe but labour-heavy.
  • Version-migration mode — run instances to completion on their original version vs. migrate them onto the new model. Draining is simple but slow to fully roll out a change; migration is fast but risks corrupting in-flight state.
  • Orchestration granularity — coarse steps (few, cheaper to run) vs. fine ones (more observable and individually retryable). Finer steps give better recovery and monitoring at higher coordination overhead.

When it helps, and when it misleads

Its strength is that it lets the people who own a process maintain it as a diagram while the runtime stays correct, bakes failure-handling and compensation into every process by construction instead of leaving each team to reinvent sagas, and keeps the running system and the documented process the same thing.

Its failure modes hide in exactly the parts a diagram omits. A clean four-box flow can compile into a tangle of compensation edges, and the happy path looks identical whether or not the failure handling is right — so the compiler can lull a team into shipping a process whose recovery logic was never exercised. Compensation that assumes a step is cleanly reversible fails when it isn't (you cannot un-send an email). The classic misuse is treating the pretty diagram as the whole truth and never testing the failure paths the compiler generated. The discipline is to test the compensation and fallback routes explicitly — inject failures — because those, not the happy path, are where a workflow earns its keep.

How it implements the components

  • obligation_decomposition_map — it breaks the process model into discrete steps, each carrying the obligation (what it must accomplish) the orchestration holds it to.
  • interface_contract — each compiled step gets a typed interface to its service — inputs, outputs, timeout, retry — so the orchestration and the services agree at the boundary.
  • rollback_and_manual_fallback_path — its signature: the compensation and manual-fallback routes it generates for every step, the failure behaviour a diagram leaves out.
  • operational_feedback_and_regeneration_trigger — runtime signals from live instances (stuck steps, repeated failures) feed back as triggers to revise and recompile the model.

It compiles process control-flow, not decision logic: the rule set that decides an individual case (source_intent_specification, unsupported_case_and_exception_policy — that's Policy-to-Rule-Engine Compilation) and the static declarations the steps read and write (constraint_set — that's Schema and Configuration Generator) come from siblings; it orchestrates the process, it does not decide the case or define the data.

Notes

A workflow compiler orchestrates when steps run and what to do when they fail; it does not decide whether an individual case qualifies — that is the rule engine's job (Policy-to-Rule-Engine Compilation). The two are complementary and often paired, and conflating them produces the familiar smells: a decision table that has swollen into a workflow, or a workflow clogged with business rules that belong in a rule set.

References

[1] The saga pattern (Garcia-Molina and Salem, 1987) handles a long-running transaction that cannot hold a lock for its whole duration by giving each step a compensating action that semantically undoes it, so a failure late in the sequence is recovered by running the compensations in reverse. It is the standard answer to "we already charged the card and now cannot ship," and it is what a workflow compiler wires in automatically. ↩