The three failures that reach production
A workflow that breaks in production usually failed in one of three ways, and they want different defences. The first is structural: a field mapped to a key the upstream node never emits, a branch with no path out, a credential that was never selected. The second is environmental: the graph is fine, but the token expired, the scope is missing, or the endpoint moved. The third is semantic: everything runs, and the result is wrong — the wrong customers get the email.
Only the first can be caught by reading the graph. The second needs a real connection. The third needs a human to look at real output. A process that treats them as one step is likely to miss two of them.
Step one: validate the graph, not the idea
Many structural problems can be found from the graph alone. Every node in OCNORA is generated from a schema, so a saved graph can be checked against those schemas before anything executes. Workflow Health does that pass on every save and publish: it checks each node for required fields, expression syntax, references to nodes that exist and edges that make sense, and reports what it finds.
- Expressions with a syntax error, or that point at a node that does not exist.
- Nodes with a required setting left empty.
- Edges that do not make sense where they are drawn.
This pass runs before the workflow makes a single API call. Treat a red validation as a compile error rather than a note about style. Read a green one more narrowly: the checks it runs found nothing, which is not the same as the graph being free of every structural mistake.
Step two: dry run with the side effects held back
Validation cannot tell you that a token expired last Tuesday. For that the workflow has to talk to the real world — which is exactly what you were trying to avoid. Workflow Health handles it in two passes. Pre-flight exercises each connection with a harmless call, so an expired token, a revoked key or a missing scope surfaces there. The dry run then executes the graph with side effects suppressed.
What the dry run gives you is the shape of each step’s output before the first real trigger, which is where most mapping assumptions quietly die. Pre-flight is what tells you a scope is missing before a customer does.
Step three: one record, watched
The first live run should touch one record, and somebody should look at what it did. Not a sample of a hundred. One. If the workflow emails customers, email yourself first. If it writes to a CRM, write to a record you created for the purpose.
For the steps that stay risky after launch, the answer is not more testing — it is an approval in the path. A human-in-the-loop step parks the run, shows a person the payload about to be sent, and waits. It costs a few minutes on the runs that matter and nothing on the runs that do not.
What to keep once it is live
The three steps above are a launch procedure. Production needs the standing version of the same idea: every run recorded with its inputs and outputs, so a wrong result can be read back rather than reconstructed from memory; budgets on anything that spends money, so an agent in a loop is held rather than left billing (a budget is checked before each model call and reconciled after it, so a call already under way can still take spend past the cap); and validation that re-runs on every save, because the second version of a workflow is written faster and read less carefully than the first.
Start from something that already runs if you can. Templates in the template library are validated against the node registry in our test suite and install as drafts, so you get to do step three on a graph that has already passed those checks.
