Vendor and Product Reality
Camunda built Zeebe specifically to overcome the throughput limits of its earlier relational-database-backed engine. Zeebe partitions process state across brokers in a Raft-replicated cluster. Each partition is a self-contained log; each broker owns a subset of partitions; clients submit commands through a gRPC gateway and the gateway routes them to the partition that owns the relevant process instance. Job workers, external processes that perform service tasks, poll for activated jobs and report completion back through the same gateway. Exporters stream the event log to downstream systems for monitoring, audit, and analytics.
The result is a workflow engine designed for high-throughput orchestration that scales horizontally by adding partitions and brokers. BPMN models are deployed once and execute many times. The engine's internal logic, token movement, gateway evaluation, timer firing, message correlation, is encoded in the broker. Customers like banks, telcos, and large-scale order-management platforms run Zeebe because the throughput envelope and the operational characteristics match the workload. The technical execution at the orchestration layer is mature. There is no claim here that Zeebe fails at what it sets out to do.
The architectural question is where the rules that govern each running instance live, and what travels with the instance when it moves through the system.
Architectural Axis: Where Authority Lives
In Zeebe, a process instance is a token position plus a payload of process variables. The rules that govern that instance, which sequence flows are valid, which conditions gate which gateways, which job types are dispatched to which workers, which authorization context applies to which task, are encoded in the BPMN model deployed to the broker and in the configuration of the gateway, the workers, and the exporters. The instance carries the variables. The broker carries the rules. When a step executes, the broker consults its deployed model and its configuration, decides what is allowed, and emits the corresponding events.
This is a clean separation for a pure orchestration engine, and it is the axis along which the two architectures differ. With rules held broker-side, scaling the broker scales execution throughput, and the governance applied to each unit of throughput is a function of the broker's deployed model and configuration rather than of the instance. Every partition runs the same deployed model with the same configured handlers. The alternative organization is for a process instance to carry its own scoped policy, its own authorization context, its own data-handling constraints, and its own trust-slope requirements, and to have that scoped policy evaluated at each step regardless of which partition or which broker happens to be processing the instance at that moment.
The event stream follows the same axis. Zeebe's event sourcing, as publicly documented, records execution facts: token moved here, job activated, job completed, variable updated. A data-side architecture adds a second kind of event alongside those, of the form "at this step, this policy was evaluated against these inputs and admitted the action." The distinction is between an audit log that answers "what did the workflow do" and one that also answers "what authorization did each step act under." For workflows that orchestrate agent actions, cross-tenant data flows, or regulated operations, recording governance evaluations as first-class events is what lets a single log carry both execution and authority.
The consequence is a question of proportion. Where governance is a property of the broker's configuration, adding instances, partitions, and brokers raises throughput while the governance record per unit of throughput stays a function of that shared configuration: each workflow receives the same broker-side policy and leaves the same shape of trace. Where governance is a property of the instance, the two quantities move together.
What the Execution-Platform Primitive Provides
The execution-platform primitive inverts the locus of authority. Rules are not attached to the broker; they ride with the data. A process instance carries, in addition to its variables, a credentialed policy structure that scopes what the instance is permitted to do. At each step, the executor, whether broker, worker, or sidecar, admits the candidate action against the instance-resident policy. The admission produces a governance event that becomes part of the same event log as the execution events. The audit log records both what happened and the authority under which it happened.
Because the policy travels with the instance, governance scales with throughput by construction. Doubling the partition count doubles both the execution capacity and the governance applied to each unit of execution. Heterogeneous policy, instance-specific authorization context, tenant-specific data constraints, workflow-specific trust requirements, becomes natural rather than awkward. The broker no longer needs to be the canonical source of governance; it can be a participant in evaluating policy that the instance itself carries.
Trust-slope validation, in particular, becomes a partitioned operation. The slope from the workflow's initiator to the current actuator is recorded in the instance's policy structure and re-evaluated at each step. A step that would extend the slope beyond what the policy admits is rejected before it executes. The rejection is itself a governance event in the log.
Composition Pathway With Zeebe
The integration with Zeebe is staged. The first stage attaches the credentialed policy structure to the process instance as a reserved variable, and inserts an admissibility evaluator into the job-worker dispatch path. Workers receive both the job payload and the policy structure; the worker admits the job against the policy before executing; the admission emits a governance event through a Zeebe exporter. Existing BPMN models continue to deploy unchanged; existing workers continue to function; the policy is additive.
The second stage moves the evaluator inside the broker, so that gateway evaluation and sequence-flow decisions also pass through the policy. Zeebe's exporter mechanism becomes the natural channel for governance events; the same downstream systems that consume execution events consume governance events alongside them, and audit, monitoring, and analytics gain governance visibility without a separate pipeline.
The third stage propagates the policy structure across workflow boundaries. A subprocess inherits the parent's policy; a message-correlated start event admits against the originating instance's policy; a workflow that calls another workflow propagates a scoped derivative of its own authority rather than relying on broker-side configuration to determine what the called workflow may do. The result is an execution platform where authority is a property of the data flowing through the system, not a property of the system the data flows through.
Commercial and Licensing Posture
Camunda's commercial position with Zeebe is strongest in regulated industries, banking, insurance, telco, where workflow throughput and operational maturity are non-negotiable and where audit obligations are heavy. These are also the industries where the question of where authority lives surfaces first: regulators are increasingly asking not only what a workflow did but under what authorization each step acted, and an answer grounded in a per-instance governance record speaks to that question directly. Workflows that orchestrate AI-agent actions, cross-tenant data flows, or counterparty-sensitive operations will face this question first.
Adopting the execution-platform primitive as the data-side authority layer above Zeebe turns that question into a differentiator. Zeebe's throughput remains the throughput story; the addition is that every unit of throughput carries its own credentialed policy and emits its own governance event. The patent is positioned at the layer that the regulatory trajectory targets, the layer where authority lives, and the additive integration model means existing Zeebe deployments can absorb the primitive without re-architecting the broker. Licensing terms contemplate per-cluster and per-throughput structures appropriate to enterprise workflow procurement, and the composition pathway preserves Camunda's existing commercial relationships with the customers most exposed to the governance question. Workers, exporters, gateway clients, and BPMN models continue to function unchanged; the addition is that each instance carries its own credentialed scope and emits its own governance trace, so the answer to "under what authority did this step act" stops being a function of broker configuration and becomes a property of the workflow data itself.
Embodiments and Variations
The data-side authority approach is not tied to Zeebe or to BPMN. A skilled implementer can realize it wherever a unit of work moves through executors. The credentialed policy structure can be carried as a reserved process variable, as a message header, as a side-channel record keyed to the instance identifier, or as a signed envelope wrapping the payload. The instance-resident structure includes, in various embodiments, an intent descriptor, a context block, a memory or lineage field recording prior transitions, a policy reference resolving to one or more cryptographically signed policy objects, and a mutation descriptor scoping what transformations the step may perform. The admissibility evaluator can sit inside the broker, inside the job worker, in a sidecar alongside the worker, or in a gateway interceptor; it evaluates the candidate action against the instance-resident policy and against the recorded trust slope from initiator to current actuator, and it emits an admission or rejection record into the same event log the execution events flow through.
Trust zones in this model are logical enforcement boundaries applied through policy references rather than physical partitions, so an instance crossing from one zone to another re-evaluates against the destination zone's constraints without any central authorization service. Identity is resolved from lineage and behavioral slope continuity rather than from persistent static credentials, so a rehydrated or migrated instance is validated by the coherence of its trajectory rather than by a long-lived key. These variations, staged additive integration, in-broker evaluation, cross-workflow policy derivation, zone-scoped enforcement, and slope-resolved identity, are alternative and combinable embodiments of the same primitive.
Disclosure Scope
The mechanisms attributed to the execution-platform primitive in this article, instance-resident credentialed policy, runtime admission of candidate actions prior to mutation or propagation, trust-slope validation across execution cycles without persistent static credentials, governance events recorded into an auditable execution trace, scoped trust zones, and lineage-resolved identity, are disclosed in United States Patent Application 19/230,933. This article is a dated public description of that inventive step and its application to workflow-orchestration architectures. All statements about Zeebe and Camunda are external context describing a real, independently developed product at the architecture level; they are provided for comparison and are not claims of the filing. Where this article describes what Zeebe does, it describes publicly documented behavior of that product; where it describes what the primitive does, it describes the disclosure of United States Patent Application 19/230,933.
