Engine selection direction

Installation-time engine selection#

The documented engine-selection requirement proposes choosing the current Matrix Workflow engine or Elsa during a fresh installation. It is a recorded direction for implementation, not a claim that the two implementations are already interchangeable.

The intended boundary preserves participant integration while allowing the installation to select its runtime and designer. The selection belongs to installation configuration, not to a process author or an end user.

Proposed choices#

The installer would configure the matching implementation and its persistence migrations. Normal startup would compose only the selected implementation. Exact configuration keys and package versions have not been established by the requirement.

Contracts that must remain stable#

Participants should retain their existing enrollment, workload identity, manifest, schema registration and approval procedure. The event, command and receipt meanings must remain consistent, including correlation, idempotency and uncertain-outcome reconciliation.

Human forms and business transactions remain participant-owned. The selected engine owns authoritative human-task state; Messages remains the common inbox. Existing identity adapters continue to resolve users, groups, stable principal references, tenant scope and current permissions.

The requirement does not ask participants to produce Elsa-specific manifests or different wire payloads. Installation-specific addresses and credentials remain ordinary protected deployment bindings.

Proposed implementation boundary#

The abstraction belongs inside Matrix Workflow. It needs narrow implementation ports where the common integration responsibilities invoke engine behavior:

• Starting work and accepting eligible events.
• Accepting service results and producing existing outward receipts.
• Querying or cancelling execution.
• Performing human-task operations and generating task projections.

Startup dependency injection would select the current-engine adapter or Elsa adapter. Internal worker leases, engine database tables, compiler details, scheduler advancement and Elsa bookmarks remain implementation details.

Both designers would use approved catalog-backed capabilities and human bindings. An Elsa implementation would need suitable Studio extensions, verified against the selected released packages. A common participant contract does not require identical designer features, definition formats or persistence schemas.

Explicit exclusions#

The requirement does not include runtime switching, per-process engine choice, simultaneous engines in one installation or automatic cross-engine failover. It also excludes migrating running instances, pending human tasks or history between engines.

There is no promise of automatic definition conversion, designer interchange or feature parity between the current restricted BPMN profile and Elsa. Changing an existing installation's engine is a separate migration project, not an established configuration toggle.

Acceptance required before availability#

Acceptance would demonstrate two separate fresh installations with the same participant fixture and registration/message contracts. Each installation would exercise registration, approval, capability selection, a service operation, a human task using an existing participant form, Messages delivery and receipt-driven continuation.

The verification must also cover duplicate delivery, restart recovery, uncertain effects and current authorization. Participants should need no code or wire-contract changes based on the selected engine. Only one task authority and the selected engine's workers and migrations should run.

Until that implementation and acceptance exist, use the current release's documented execution profile and integration contracts. The BPMN profile and participant guide describe those boundaries without assuming an Elsa adapter is available.