Capabilities

What Zoumadi runs today, in the order you meet it: the models it executes, the ways you reach it, and what a running deployment gives your operators.

Workflow execution

Zoumadi takes your Camunda 7 dialect BPMN files as they are and executes a declared linear subset of them — none start and end events, external service tasks and call activities — with no conversion step and no second dialect to learn. New model versions deploy while existing instances keep running, and every running instance stays pinned to the version it started on, so a deployment never moves work mid-flight. Process variables use a declared set of types with fixed size limits, copied in order.

Reaching the engine

Commands and jobs travel over a NATS-native protocol rather than a REST layer in front of one. Your service task code runs as external worker processes that receive, complete or fail jobs over NATS, which keeps your business logic in your own deployment and out of the engine’s transaction. Zoumadi can also be embedded directly in a Java application through its own client API.

Security and identity

Zoumadi carries subject-level authentication and permissions at the NATS layer, expects external traffic to arrive through your own gateway, and leaves the identity directory where it already lives — your own OIDC provider.

Running a deployment

Each partition has exactly one writer at a time and fails over locally. Backup and total-loss restore are built mechanisms. Metrics, structured logs and traces come out of a built telemetry surface, so a deployment observes Zoumadi with the tooling it already runs.

The operations view

Cockpit is the separate, read-only window onto what Engine is running.

Data governance

Zoumadi ships the technical mechanisms a data-protection process needs to work with.

Is Zoumadi a fit? — the shape of process that suits it, and how a model-by-model assessment works.
Roadmap — the direction of travel, without dates.

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.

External workers receive, complete or fail service-task jobs over NATS job subjects, with redelivery on failure. — push, redelivery, completion and failure handling.

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.

Process variables use a declared set of types with fixed size limits, and concurrent job completions merge deterministically. — for the supported variable types and size limits.

Commands and jobs travel over a NATS-native protocol rather than REST or gRPC; a deployment still needs its own external ingress for traffic from outside the cluster. — callers must follow the documented at-least-once and idempotence rules.

Zoumadi can be embedded in a Java application through its own client API, rather than reached only over the network. — your deployment supplies the providers before production use.

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.

Cockpit is designed for people to sign in through your own OIDC identity provider, so Zoumadi keeps no identity directory of its own.

Zoumadi is designed for traffic from outside a deployment's own network to reach it through an APISIX gateway that the deployment provides and operates.

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.

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 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.

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 provides data export, restriction and rectification mechanisms that a deployment's own data-protection process can build on.