One execution path, or none

Our platform has a rule that took a while to earn, and that we now defend harder than almost anything else in the architecture: everything executes through the workflow engine. Not most things. Everything.

Why the rule exists

Systems acquire second execution paths by accident, and always for a good local reason. Something needs to run before the engine is ready. Something is too simple to justify a graph. Something is a one-off script that then becomes load-bearing.

Each of those is defensible on its own. Together they produce a system where "what happens when this runs" has several answers depending on which door the work came through, and where cancellation, retries, event history and resumability exist on one path and not the others.

The failure is never the second path. It is discovering, during an incident, that the second path was the one that mattered.

What the single path gives you

• Cancellation means the same thing everywhere. There is one place that knows how to stop work.
• State is resumable by construction. A long-running job survives a restart because the engine, not the caller, owns its progress.
• History is free. Every run emits the same event stream, so "what did it do last Tuesday" is a query rather than an archaeology project.
• Validation happens before execution. A graph is checked, then run. There is no path that skips the check because it was in a hurry.

What it costs

It is genuinely annoying. Small things become graphs. You write a node for something that would have been four lines. Onboarding takes longer, because there is a concept to learn before anything runs.

We think that is the correct trade for a system that is going to be operated rather than demonstrated. But it is a real cost, paid up front by the people building, in exchange for a benefit collected later by the people carrying the pager. Those are usually different people, which is exactly why the rule needs to be a rule rather than a preference.