Product

Zoumadi is three separate deliverables, not one browser application. Engine runs your workflows. Modeler is where you draw and edit them. Cockpit is where you watch them run. Each one installs on its own. None of the three requires the other two, and none quietly becomes another.

The table below is the whole shape. The sections after it give each component its own room, in the same order: Engine, Modeler, Cockpit.

A model moves between these three components the way a document moves between an editor and a reader. You draft it in Modeler, you deploy it to Engine, and you watch it run in Cockpit. Each one installs and runs on its own, so you adopt them in whatever order suits your estate.

Engine

The problem Engine addresses is ordinary and specific: an organisation already has BPMN process models — often written for a Camunda 7 dialect engine — and needs somewhere to run the subset that still applies, without adopting a new modeling language or a new relational database to hold instance state.

Engine’s execution core keeps that state in a replicated log rather than a database table. A process instance’s history is the sequence of entries the log recorded for it; derived, read-oriented projections are built from that log for lookups, not the other way round. Work that a process hands off to the outside world — a service task — is pushed to an external worker over NATS rather than executed inside the engine process itself.

Engine reads its BPMN models through the CIBSeven model layer, which understands the Camunda 7 dialect. Not every construct that layer can parse is one Engine can also run: compatibility has to be checked model by model, against the supported subset described on the Capabilities page. A model that relies on constructs outside that subset is not assumed to run unchanged on Zoumadi.

Running Engine has prerequisites beyond the jar itself: a NATS JetStream cluster, one or more external worker processes for your service tasks, and — for anything reachable from outside the deployment’s own network — an ingress gateway in front of it. The Requirements page lists these plainly, each with its own status.

Modeler

Modeler is where a process designer works on a diagram before it goes anywhere near Engine. It runs entirely in your browser: opening it needs nothing more than the page itself, and a diagram you create or edit stays in that browser tab until you download it. There is no save-to-server action and no live connection to an Engine deployment — moving a model from Modeler to a running system is a deliberate, separate step you take with the downloaded file.

Modeler’s palette comes from a general Camunda 7 editing library, so it is a full drawing surface: Engine’s own deploy-time check is the one place that decides what a given model runs. If you want to know whether a diagram you already have is a candidate, Is Zoumadi a fit? walks through how that question gets answered.

Cockpit

Cockpit is the enterprise operations application: a place to look at what Engine is doing, without a way to change it from there. It is read-only by design and never mutates a process instance itself. A person opens Cockpit through a deployment-supplied OIDC identity provider, and the pages it renders read bounded projections of Engine’s own state rather than holding a separate copy of the truth. Its current status is stated below with its source and date.

Cockpit is licensed as an enterprise component, alongside Engine, under a written agreement rather than bundled in by default. If you want to know what its current build status means in practice before asking further questions, discuss it directly.