Zoumadi

Roadmap

Three stages, describing direction rather than delivery. For what a specific BPMN construct does today, the Capabilities page is the page to read.

Proven

The core Zoumadi runs on today: a replicated log with no relational database underneath it, online deployment of new model versions, version pinning so a running instance is never moved mid-flight, and a single writer per partition with local failover.

Maturing

Production capability building on that core: calling one process from another, authentication of the command path, backup and restore, and the read-only operator Cockpit. This stage hardens what already runs.

Growing

Wider BPMN coverage: gateways and expression evaluation, multi-instance and subprocess behaviour, and event-based waits such as timers and message correlation.

Nothing above is a commitment to a date.

Zoumadi runs a declared subset of Camunda 7 dialect models — none start/end events, external service tasks and call activities — without converting them. Compatibility is assessed model by model, and anything outside the subset is refused at deploy time rather than run incorrectly. — for the supported linear subset.

Zoumadi can deploy a new, compatible version of a workflow while other instances keep running, without a maintenance window.

Each running process instance stays pinned to the model version it started with; a later redeploy never moves it in flight. — for the current deployment path.

Each partition has exactly one writer at a time and fails over locally to a standby without a cross-region failover proof. — within a single cluster; multi-region is not covered.

A process can call another process as one linear step, naming the callee by its process id and copying typed variables in and out by name. — by static process id, with latest, version or deployment binding and ordered typed variable copies.

Zoumadi has a built backup and total-loss restore mechanism; a deployment must still supply and prove its own storage authority and restore evidence. — your deployment decides who may invoke it.

Zoumadi supports NATS subject-level authentication and permissions; your deployment authors and issues its own credential grants. — your deployment writes its own NATS credentials and grants.

Zoumadi Cockpit is a separate, read-only, server-rendered operations application: it reads bounded projections of Engine state, signs people in through an external OIDC identity provider, keeps sessions encrypted and records durable audit evidence of sensitive reads. No browser ever talks to NATS.

Zoumadi emits metrics, structured logs and traces through a built telemetry mechanism; a deployment still owns wiring alerting and dashboards to it. — no external endpoint is published yet.