OmniFlowFrom manifest to proof.
One small service takes a workflow from a file to a recorded, explainable run. Here is every part, and the limits that come with it.
Four stages, each one checkable.
1 · Author
Write a manifest by hand, import a crontab or a shell script, or describe the work and review the draft. Drafts are versioned and can require a second reader.
2 · Check & plan
The manifest becomes an immutable plan with a content hash. Unknown capabilities, bad references and unsafe patterns are errors you see before anything runs.
3 · Run
Triggers: manual, schedule, signed webhook, event or another workflow's completion. Dry runs, canary percentages and a kill switch are built in.
4 · Explain
Every attempt, retry and approval is recorded. Ask any run why it retried or stopped and get a plain-language answer.
What OmniFlow promises, and how.
| Promise | How it is kept |
|---|---|
| An effect happens at most once | An idempotency key is claimed before the step acts; replays return the recorded result. |
| Only the right failures retry | Failures are classed; contract, authorisation and business failures never retry. |
| Partial work can be undone | Steps declare a compensation; failures roll back in reverse order. |
| History cannot be rewritten | Events are hash-chained per tenant; verification is a command and a button. |
| A paused run costs nothing | Approvals and waits are state, not running processes. |
What it is not.
Knowing the limits is part of the product.
Single node
One process on one SQLite file. High availability means restarting quickly, not failing over.
No cluster
If you need a distributed engine today, OmniFlow is not the right tool yet.
Retention is coming
Old runs and audit history are kept; archival and retention policies are not built yet.
Run something that matters.
Request early access and be first in line when the beta opens.