Author: Sergey Lukyanchikov, C-NLTX/Open-Source
Disclaimer: The views expressed in this document reflect the author's subjective perspective on the current and potential capabilities of jBPM.
TL;DR: Zero "quantum supremacy". Zero "agentic orchestration". Zero other hype. Just an approach to achieving an efficient quantum-assisted automation using 100% free open-source components (except for Azure).
In my previous article, I discussed the rationale for adopting jBPM as an AI orchestration platform. This article extends that discussion by examining jBPM’s ability to automate quantum computations and to incorporate their results into business processes and related analytical workflows:
Figure 1 Cannibalization Analysis solution running on jBPM and accessed by SuiteCRM users
A Use Case for Quantum
Correlation analysis is one of the fundamental analytical tools used in virtually every business domain. Correlations in sales volumes, often referred to as cannibalization when the focus is on negative correlations among products or promotions, are valuable not only as analytical results in their own right but also as inputs to a wide range of subsequent analytical and decision-making methods.
A common challenge in applying correlation analysis is the lack of sufficiently complete observational data. Reliable correlation estimates typically require observations with few or no missing values across multiple products and time periods. When the analytical focus shifts from products to promotions, data scarcity often becomes even more pronounced. This is because promotional events are represented far more sparsely in sales datasets, further reducing the number of usable observations available for analysis.
To mitigate the bias that may arise from computing correlation coefficients on a fully “sanitized” sales and promotion history, that is, a dataset from which periods with missing observations have been excluded, we apply two complementary techniques:
· Introducing an externally generated perturbation (i.e., random values independent of the historical data), which is combined with the sales-based results to reduce dependence on the observed history; and
Figure 2 An externally generated correlation matrix used to introduce perturbations into sales-based correlations
· Averaging (iteratively) the sales-based correlation matrix with the perturbation matrix
Figure 3 A sales-based correlation matrix (big one) iteratively averaged seven times with a quantum-generated perturbation matrix
Why is it important that the perturbation be generated externally? In this way, we ensure that it does not follow the same distributions already present in the historical data, making it a genuinely independent perturbation. However, we would like to go even further: we want our perturbation to be not only independent but also genuinely random, i.e., generated using true random numbers rather than pseudorandom numbers produced from a deterministic sequence of values. To achieve this level of randomness, we will use quantum computing.
How Quantum Generates Genuine Randomness
We use a very straightforward approach: the qubits in the input register are prepared such that, after applying a Hadamard gate to each qubit and measuring, they produce a statevector whose length is sufficient to enumerate n(n-1)/2 cells in the upper triangular part (excluding the diagonal) of an n x n correlation matrix. A register of m qubits has a statevector of length 2ᵐ. Since we apply a Hadamard gate to each qubit, m must be a positive integer, i.e., m≥1:
Figure 4 A quantum circuit with three input qubits, resulting in a statevector of length 2³ = 8
Therefore, the condition is 2ᵐ ≥ n(n-1)/2, m≥1. The minimum number of qubits is thus given by: m = max(1, ⌈ log₂(n(n-1)/2))⌉). For n=2, we have n(n-1)/2 = 1, and ⌈ log₂(1)⌉ = 0. However, since m≥1, the minimum is m=1. Indeed, a single qubit after application of the Hadamard gate yields H|0⟩ = (|0⟩+|1⟩)/√2, whose statevector has at least two amplitudes, thereby satisfying the requirement of at least one representable element. In the table below, the minimum number of qubits m has been computed for values of n ranging from 2 to 10:
Table 1 Minimum number of qubits required to enumerate n(n-1)/2 elements of a correlation matrix (diagonal excluded)
We observe from the above that, as the size of the correlation matrix grows linearly, the number of required elements grows quadratically, whereas the minimum number of required qubits grows logarithmically.
By repeatedly generating and measuring the circuit described above an appropriately large number of times, and symmetrically populating the matrix (with respect to the diagonal) using empirical averages of the corresponding entries of the measurement bitstrings, we obtain a stochastic model of a correlation matrix whose elements exhibit convergence toward their expected values and a well-defined central tendency.
A Practical Example: Cannibalization Analysis
Our Cannibalization Analysis solution is based on the following business scenario: customers of a network of cafes participate in promotional offers (promotions) and receive rewards for their participation. Based on a given sales history, we aim to identify which promotions cannibalize each other (i.e., exhibit negative correlations in reward amounts). At the same time, we seek to attenuate the bias present in the historical data to enable the use of cannibalization analysis results in downstream modelling, such as sales price optimization. As discussed previously, this is achieved by “mixing” historical promotion correlations with externally generated noise – specifically, perturbation matrices computed using quantum methods.
One of the most likely systems to consume cannibalization analysis is a CRM system; therefore, we initiate our workflow in SuiteCRM (the open-source CRM software) by creating an analysis scenario record:
Figure 5 Creation of a cannibalization analysis scenario: defining the “cannibals” and setting the number of perturbation mixes
After saving, the analysis scenario record is added to the record history and becomes the source of input parameters for cannibalization analysis runs initiated by the user who created the scenario:
Figure 6 An analysis scenario record added to the record history
To initiate an analysis run, a user creates a request in SuiteCRM that is sent to the jBPM server, which launches a business process implementing the cannibalization analysis logic and orchestrating quantum computations in Microsoft Azure:
Figure 7 A cannibalization analysis request created in SuiteCRM triggers computations orchestrated by jBPM
The business process launched by jBPM sends a computation script, together with the scenario parameters received from SuiteCRM, to a Microsoft Azure quantum workspace, where a quantum computing job is initiated:
Figure 8 A quantum computing job initiated by a jBPM business process in a Microsoft Azure quantum workspace
The output of the executed job is returned to jBPM, where it is injected into the business process, allowing execution to continue:
Figure 9 Results of the executed quantum computing job returned to the business process in jBPM
The quantum artifacts received from Azure by jBPM are available as business process variable values in the jBPM logs:
Figure 10 Azure artifacts in the jBPM server logs
The jBPM business process returns the cannibalization analysis output – the correlation matrix – to SuiteCRM, where the user can view the results in the newly created analysis run record:
Figure 11 Cannibalization analysis output returned to SuiteCRM and recorded in a newly created analysis run record
We observe that one of the products (promotions) selected in the scenario record does not appear in the resulting correlation matrix. The reason is that one of the items is not present in the sales history.
The resulting correlation matrix is stored in a PostgreSQL table:
Figure 12 The resulting correlation matrix persisted in PostrgreSQL
It is natural to conclude this practical example by demonstrating that the Cannibalization Analysis solution has successfully passed testing with three concurrent users:
Figure 13 Three testers concurrently working on the Cannibalization Analysis solution
What Makes jBPM a Quantum Orchestration Platform?
Having reviewed the text thus far, it is logical to ask whether jBPM’s quantum orchestration capabilities generalize beyond the above practical example to a broader range of use cases and quantum computing providers. Below, we provide a set of illustrative examples, allowing the reader to draw their own conclusions.
In certain cases, we may first perform quantum circuit automation locally, i.e., using a quantum simulation environment installed directly on a local machine or on one of the machines within a local network:
Figure 14 A jBPM business process implementing orchestration of a local quantum circuit
Our quantum circuit execution can be orchestrated inside a quantum computing provider of our choice, assuming that the provider exposes an API sufficient to submit execution code and retrieve the corresponding results:
Figure 15 SuiteCRM initiates a jBPM business process that orchestrates quantum computations inside the IBM Quantum Platform
The above arguments support our proposed positioning of jBPM as a quantum orchestration platform, in combination with the arguments presented in my previous article.
For more: C-NLTX/Open-Source
