BPMN to Smart Contract by Business Analyst

C. G. Liu; D. Jutla; P. Bodorik

REVIEW 3 major objections 3 minor 13 references

BPMN to Smart Contract by Business Analyst

T0 review · 3 major / 3 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read A business analyst alone can turn BPMN and DMN models into deployable smart contracts.

desk verdict A plausible but unproven extension of the authors' TABS pipeline; the DMN-to-code step is asserted, not demonstrated. read the letter →

arxiv 2505.22612 v1 pith:ZKLGBKP6 submitted 2025-05-28 cs.SE cs.CR

C. G. Liu , P. Bodorik , D. Jutla This is my paper

classification cs.SEcs.CR

keywords smartcontractgenerationBPMNDMNdecisiontablesbusinessanalystblockchainmodel-drivenengineeringTABS

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper argues that the last programming step in its smart-contract pipeline—writing the business logic of each BPMN task—can be moved into DMN decision models, leaving the Business Analyst in full control. If the BA can draw the process flow in BPMN, annotate how documents move between tasks, and express task decisions as DMN decision tables, the TABS tool transforms those models directly into smart contract methods and a monitor contract without a software developer. The payoff is that process-oriented blockchain applications, such as sales, transport, and supply-chain workflows in small and medium enterprises, could be built and maintained by business staff rather than blockchain programmers.

What carries the argument

The load-bearing machinery is the multi-modal DE-FSM model: Discrete Event modeling represents flow and coordination, Finite State Machines represent task functionality, making the generated coordination code blockchain-agnostic. The paper's new piece is DMN modeling of task logic: a BPMN business-rule task carries a decision table, and JSON annotations on BPMN data associations specify which fields of which off-chain documents are marshalled into each generated contract method. A monitor smart contract deployed by the tool manages invocation and sequencing of the task methods, and TABS is the proof-of-concept transformer that consumes the BPMN/DMN models and emits the contract code.

What would settle it

Run TABS on a realistic BPMN/DMN model whose task logic requires FEEL looping, ranges, date functions, or external HTTP calls. If any such model fails to import or transform without the analyst writing code, the no-developer claim is false for that class of applications.

Watch

Extended reading notes

Core claim

The central claim is feasibility: a BA who successfully models a blockchain application with BPMN for flow and DMN for task-level business logic can generate deployable smart contracts without developer assistance. The argument separates flow control from task semantics—the coordination of activities is encoded in a blockchain-agnostic DE-FSM model, while each task's behavior is self-contained because it reads only the contract state and the marshalled inputs described by JSON annotations on the BPMN model. A DMN business-rule task replaces hand-written task code for decision logic, and its outcome is routed by an exclusive gateway; when the decision fails, the contract fails and triggers the recovery procedures built into the tool. The paper thus presents TABS as a proof of concept that the no-developer workflow is achievable for the class of applications whose business logic fits simple decision tables.

Load-bearing premise

The load-bearing premise is that every piece of business logic a real contract needs can be captured in the simple decision tables the tool currently supports, so the Business Analyst never has to hand off nontrivial task logic to a developer.

Editorial extensions

If this is right

An SME with no blockchain programmers can have a BA produce deployable contracts for sales, transport, insurance, and supply-chain processes.
Only content-addressed hashes of off-chain documents and decision outcomes go on-chain, keeping generated contracts small and the audit trail verifiable.
The same BPMN/DMN models can be transformed for both supported target blockchains, because flow control is blockchain-agnostic and only task scripts depend on the platform.
The approach is a stepping stone to a BPMN-to-smart-contract service where XML descriptions of the models are the input and deployed contracts plus the monitor are the output.
The prior extensions for nested long-running transactions and contract repair/upgrade carry over to the BA-only workflow.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

Editorial inference: the no-developer claim is currently bounded by the tool's support for simple decision tables; the immediate test is whether FEEL-based logic such as loops, ranges, date arithmetic, and context expressions can be imported and transformed without hand-written code.
Editorial inference: if the claim generalizes, correctness pressure shifts from coding to modeling, so validating that the BA's DMN tables and JSON annotations faithfully capture the business rules becomes the key quality problem.
Editorial inference: a natural benchmark the paper does not provide is a side-by-side comparison of generated versus hand-written contracts on gas cost, security, and maintainability for the same workflows.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Quick take: the paper has one real idea — let business analysts write DMN decision tables and feed them into the existing TABS transformation — but the load-bearing transformation from DMN to smart contract code is never shown. You'll find a clear description of the intended architecture, a simple combine-harvester sale example, and an honest admission of what's not supported, but no generated contract, no transformation rules, no evaluation.

What's actually new: prior work [10-12] handled BPMN flow control. Adding DMN as the notation for task-level business logic is a sensible, incremental step that fits the low-code/SME narrative. The paper is readable and the separation between blockchain-agnostic flow and task-specific scripting is a useful framing. Credit where due: the authors explicitly say only simple decision tables are supported, and they are upfront that in the worked example the BA or an operator performs many tasks off-chain while the contract only records CIDs. That is more honest than most position papers.

The soft spots are real. Section IV says FEEL support is assumed without design challenges — that is a big leap, since FEEL has loops, ranges, and three-valued logic, and compiling all of that to EVM or HLF code is not trivial. Section V quietly shrinks the claim: for the analyzed use cases, tasks execute off-chain and the contract just exchanges document hashes. In that world the DMN table only picks an abort path, so the headline 'business analyst generates deployable smart contracts' reduces to 'business analyst can generate a contract that records CIDs and does a simple comparison.' The core claim depends on the DMN-to-code transformation, and the paper gives no evidence it works. Self-citation is heavy, but that is not the problem; the problem is missing artifact and missing evaluation.

Who is this for? Readers in the BPMN-to-smart-contract subfield will want to know about the DMN integration as an advance over TABS+R. It is a workshop-level contribution or an extended abstract, not a complete systems paper.

Recommendation: send it to peer review, but with the clear expectation that the authors release the TABS/R tool, show a concrete end-to-end transformation from a DMN table to deployed bytecode, and clarify how much of the claim survives when tasks are done off-chain. If they can do that, the idea is worth publishing; if not, the paper is a proposal, not a result.

Referee Report

3 major / 3 minor

Summary. The paper claims that a business analyst (BA) who can express a blockchain application's requirements in BPMN and DMN models can use the authors' proof-of-concept tool TABS+R to generate deployable smart contracts directly from those models, without developer assistance. The paper describes the overall architecture, how a BA documents information flow in BPMN using JSON annotations, how DMN decision tables can be attached to business-rule tasks, and walks through a simple sale-of-goods example. The central claim is that the DMN business logic is transformed into smart contract method code, and that TABS+R automates this transformation. However, the paper provides no transformation rules, no generated contract code, no evaluation results, and no released tool; it also states that only simple decision tables are currently supported and that FEEL support is assumed without design analysis. Section V further narrows the demonstrated scope by explaining that many tasks can be executed off-chain with only CIDs recorded on-chain, and that the BA or an operator manually performs the actual activities.

Significance. If substantiated, the contribution would be valuable: it would lower the barrier to smart contract development by letting business analysts, not programmers, generate contracts for process-oriented applications using two OMG standards. The architecture is plausible and the paper correctly identifies that flow control can be made blockchain-agnostic while task logic remains the main coding challenge. The paper also honestly acknowledges some limitations, such as the proof-of-concept status and the need for security validation. However, the central feasibility claim is not demonstrated in the manuscript. The key step—transforming DMN decision logic into executable smart contract code—is asserted rather than shown, and the supporting evidence rests on the authors' prior publications rather than on material presented here. The paper therefore currently reads as a position statement or a research-in-progress report rather than a validated methodology.

major comments (3)

[Section IV, FEEL paragraph] The central claim of the paper requires that DMN business logic be automatically transformed into smart contract method code. Yet Section IV states: "currently we only support simple decision tables" and dismisses FEEL support with "we do not foresee design challenges." The paper provides no transformation rules for even the simple decision table case, no example of generated Solidity or Go code, and no evaluation of whether the generated code correctly implements the decision logic. This is a load-bearing gap because without this transformation, a BA cannot generate a useful contract for any nontrivial task logic, which collapses the headline claim.
[Section V, off-chain task execution] Section V significantly undercuts the claim that the smart contract encodes the business logic. It states: "when task executions can be performed off-chain, the task script code does not need to be provided on-chain" and describes how the BA or an operator "performs the actual activities represented by some of the tasks, while the smart contract records the result." In the presented use case, the smart contract appears limited to recording CIDs and the DMN decision table only selects an abort path. The paper does not demonstrate a scenario in which the DMN table directly controls on-chain branching beyond a simple abort/continue decision, so the claimed ability to generate contracts for arbitrary DMN business logic is not supported by the described example.
[Section II and Section VII] The paper claims that TABS+R "automates the generation of smart contracts from BPMN models" and concludes that "we demonstrated that a BA uses the BPMN and DMN modeling to create models that are transformed into smart contracts without the assistance of a software developer." However, the tool is not released, no screenshots of generated code are shown, and no evaluation results are reported. The only evidence cited for the tool's capabilities is the authors' prior work [10]-[12], which predates the DMN extension that is the new contribution of this paper. The incremental claim of this paper—the DMN-to-code transformation—is therefore unsubstantiated by any direct demonstration.

minor comments (3)

[Section IV] The term "Friedly Enough Expression Language" appears twice and should be "Friendly Enough Expression Language." Also, "as a part of DML" should be "as a part of DMN."
[References] Reference [18] is incomplete: it gives only "Camundal. DMN Tutorial. In: https://camunda.com/dmn/" and does not include access date or a proper title capitalization. The typo "Camundal" should be "Camunda."
[Section III.B] The paper assumes the BA is familiar with JSON and FEEL, but does not justify this assumption against the typical skill set of a business analyst. This may be worth a brief discussion, especially since the abstract frames the contribution as empowering BAs without developer assistance.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper's claims are conditional and grounded in prior-work citations rather than in a self-referential reduction of an output to its own input.

full rationale

The paper does not contain a derivation in which an output quantity is defined in terms of the claimed input, nor does it fit a parameter and then report closely related data as a prediction. The core claim is conditional: 'if the BA is successful in representing the blockchain application requirements using BPMN and DMN models, our methodology and the tool ... generate the smart contracts directly from those models.' The transformation machinery is attributed to the authors' prior work ([10]-[12]) rather than re-derived here; that is a self-citation pattern, but it is not circular because the prior work is external to this paper and the current paper invokes no uniqueness theorem and does not hide an ansatz inside a citation. The principal weaknesses are evidential, not circular. Section IV admits 'currently we only support simple decision tables' and dismisses FEEL support with 'we do not foresee design challenges'; Section V narrows the on-chain role to recording the BA's off-chain activities ('the BA, or an operator trained by the BA, performs the actual activities represented by some of the tasks, while the smart contract records the result'). These passages show that 'without developer assistance' is under-supported for nontrivial business logic, but under-support is not circularity. No specific equation or fitted input is reused as its own output, so the circularity score is 0.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

The paper introduces no new physical or mathematical entities. Its load-bearing assumptions are about the capabilities of business analysts, the blockchain-agnostic abstraction of BPMN flow control, and the completeness of DMN-based business logic, all of which are asserted rather than demonstrated. The TABS+R tool and monitor smart contract are software components inherited from the authors' prior work, not independently validated artifacts.

assumptions (3)

domain assumption The BA is proficient in BPMN, DMN, FEEL, and JSON, and can express the application's requirements in these notations.
Section III.B states this assumption directly. If business analysts cannot reliably author such models, the entire no-developer workflow fails.
domain assumption BPMN flow control can be made blockchain-agnostic by translating it into a DE-FSM model coordinated by a deployed monitor smart contract, with only task code blockchain-dependent.
Section II asserts this as a key feature; correctness of the generated contracts depends on this abstraction and on the monitor, but no proof or fault analysis is given.
ad hoc to paper DMN decision tables attached to BPMN business-rule tasks can be automatically converted into smart contract method logic, and the current simple-decision-table subset will extend to FEEL.
Section IV says only simple decision tables are currently supported and FEEL support is assumed without design challenges; this underpins the claim that a BA, rather than a developer, can supply all task business logic.

how reviews work

0 comments

Cite this review

Pith. "Pith review of BPMN to Smart Contract by Business Analyst." pith.science (2026). https://pith.science/paper/ZKLGBKP6

@misc{pith2026250522612,
  author       = {Pith},
  title        = {Pith review of: BPMN to Smart Contract by Business Analyst},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/ZKLGBKP6}},
  note         = {Machine review of arXiv:2505.22612}
}

read the original abstract

This paper addresses the challenge of creating smart contracts for applications represented using Business Process Management and Notation (BPMN) models. In our prior work we presented a methodology that automates the generation of smart contracts from BPMN models. This approach abstracts the BPMN flow control, making it independent of the underlying blockchain infrastructure, with only the BPMN task elements requiring coding. In subsequent research, we enhanced our approach by adding support for nested transactions and enabling a smart contract repair and/or upgrade. To empower Business Analysts (BAs) to generate smart contracts without relying on software developers, we tackled the challenge of generating smart contracts from BPMN models without assistance of a software developer. We exploit the Decision Model and Notation (DMN) standard to represent the decisions and the business logic of the BPMN task elements and amended our methodology for transformation of BPMN models into smart contracts to support also the generation script to represent the business logic represented by the DMN models. To support such transformation, we describe how the BA documents, using the BPMN elements, the flow of information along with the flow of execution. Thus, if the BA is successful in representing the blockchain application requirements using BPMN and DMN models, our methodology and the tool, called TABS, that we developed as a proof of concept, is used to generate the smart contracts directly from those models without developer assistance.

Figures

Figures reproduced from arXiv: 2505.22612 by the authors.

**Figure 1.** System architecture for the design phase and for the execution phase (adopted from [10]) When a document is created and uploaded to IPFS, a new Content-addressed hash code IDentifier (CID) is generated. This CID is then signed and stored by the smart contract, providing a method to verify the document's authenticity, including confirming (i) authorship and (ii) immutability to ensure that the document has not been a… view at source ↗

**Figure 2.** BPMN model Once both the insurance and transport contracts are obtained and provided to the transporter, the product is delivered to its destination, represented by the DoTransp task. Once the product is received by the purchaser, the reception of the product is recorded in the Delivery document that is forwarded to the final task, RevAndFin, that reviews and finalizes the contract. Please note that the flow of acti… view at source ↗

**Figure 3.** Annotation to describe information flowing between tasks For the subsequent sections, we assume that the monitor smart contract, required by the smart contracts generated by the TABS+R tool, has already been deployed on the target blockchain. We support currently either HLF blockchain or a blockchain that uses EVM. IV. DMN MODELING We will use our simple example use case, represented by the BPMN model of [PITH_FULL… view at source ↗

Figures from the paper (2 more)

**Figure 4.** Figure 4: Creating the decision table for a business-rule task [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]

**Figure 5.** Figure 5: BPMN model with the business-rule task In addition to the simple decision tables, DMN modeling also incorporates the use of the Friedly Enough Expression Language (FEEL). FEEL was created by OMG as a part of DML using the following design principles with the aim to be …

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

13 extracted references · 5 canonical work pages

[12]

C. Liu, P. Bodorik, and D. Jutla. Automated Mechanism to Support Trade Transactions in Smart Contracts with Upgrade and Repair. Pre-accepted for publicatoin in Blockchain: Research and Applications (Elsevier journal); https://blockchain.cs.dal.ca/papers/BCRAj2-3rd-Submission-2nd-revision-2024-12-02-REPAIR.pdf

work page 2024
[1]

In our prior work we presented a methodology that automates the generation of smart contracts from BPMN models

1 BPMN Model to Smart Contract by Business Analyst Christian Gang Liu Faculty of Computer Science Dalhousie University Halifax, Canada Chris.Liu@dal.ca Peter Bodorik Faculty of Computer Science Dalhousie University Halifax, Canada Peter.Bodorik@dal.ca Dawn Jutla Sobey School of Business Saint Mary’s University Halifax, Canada Dawn.Jutla@gmail.com Abstract...

work page 2008
[5]

Lorikeet: A Model-Driven Engineering Tool for Blockchain-Based Business Process Execution and Asset Management,

Tran, Q. Lu, and I. Weber, “Lorikeet: A Model-Driven Engineering Tool for Blockchain-Based Business Process Execution and Asset Management,” in Proc. 2018 Int. Conf. on Business Process Management, 1–5; https://api.semanticscholar.org/CorpusID:52195200

work page 2018
[6]

CATERPILLAR: A Business Process Execution Engine on the Ethereum Blockchain,

O. López-Pintado, L. García-Bañuelos, M. Dumas, I. Weber, and A. Ponomarev, “CATERPILLAR: A Business Process Execution Engine on the Ethereum Blockchain,” Software Practice and Experience, 49(1). 2019, arXiv: arXiv:1808.03517. doi: 10.48550/arXiv.1808.03517

arXiv doi:10.48550/arxiv.1808.03517 2019
[7]

Controlled flexibility in blockchain-based collaborative business processes,

O. López-Pintado, M. Dumas, L. García-Bañuelos, and I. Weber, “Controlled flexibility in blockchain-based collaborative business processes,” Information Systems, vol. 104, p. 101622, Feb. 2022, doi: 10.1016/j.is.2020.101622

arXiv 2022
[14]

Decentralized collaborative business process execution using blockchain,

F. Loukil, K. Boukadi, M. Abed, and C. Ghedira-Guegan, “Decentralized collaborative business process execution using blockchain,” World Wide Web, vol. 24, no. 5, pp. 1645–1663, Sep. 2021, doi: 10.1007/s11280-021-00901-7

doi:10.1007/s11280-021-00901-7 2021
[15]

Bianchini, V

Bagozi, D. Bianchini, V. De Antonellis, M. Garda, and M. Melchiori, “A Three-Layered Approach for Designing Smart Contracts. OTM 2019 Conf., Springer Int Publ, 440–457. doi: 10.1007/978-3-030-33246-4_28

doi:10.1007/978-3-030-33246-4_28 2019
[16]

Integrated model‐driven engineering of blockchain applications for business processes and asset management

Qinghua Lu, An Binh Tran, Ingo Weber, Hugo O’Connor, Paul Rimba, Xiwei Xu, Mark Staples, Liming Zhu, and Ross Jeffery. Integrated model‐driven engineering of blockchain applications for business processes and asset management. Software: Practice and Experience 51, no. 5 (2021): 1059-1079

work page 2021

Show all 13 references

[17]

López-Pintado, L

O. López-Pintado, L. García-Bañuelos, M. Dumas, I. Weber. Caterpillar: A Blockchain-Based Business Process Management System. In Proc. of Business Process Management Workshops: BPM 2017 International Workshops, Barcelona, Spain. https://ceur-ws.org/Vol-1920/BPM_2017_paper_199.pdf

2017
[2020]

2nd ACM Int

A Review on Scalability of Blockchain. 2nd ACM Int. Conf. on Blockchain Technology (ICBCT'20), pp 1–6. DOI:https://doi.org/10.1145/3390566.3391665
[2021]

Peer Peer Netw Appl

Blockchain smart contracts: Applications, challenges, and future trends. Peer Peer Netw Appl. 2021 Apr 18:1-25. doi: 10.1007/s12083-021-01127-0

2021 doi
[2022]

Blockchain: Research and Applications (Elsevier journal), 100115

TABS: Transforming Automatically BPMN Models into Smart Contracts. Blockchain: Research and Applications (Elsevier journal), 100115. https://doi.org/10.1016/j.bcra.2022.100115

2022
[2024]

ACM journal on Distributed Ledger Technologies: Research and Practice (DLT) https://doi.org/10.1145/3654802

Tabs+: Transforming Automatically BPMN Models To Smart Contracts with Nested Collaborative Transactions. ACM journal on Distributed Ledger Technologies: Research and Practice (DLT) https://doi.org/10.1145/3654802

doi

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.

[1] [12]

C. Liu, P. Bodorik, and D. Jutla. Automated Mechanism to Support Trade Transactions in Smart Contracts with Upgrade and Repair. Pre-accepted for publicatoin in Blockchain: Research and Applications (Elsevier journal); https://blockchain.cs.dal.ca/papers/BCRAj2-3rd-Submission-2nd-revision-2024-12-02-REPAIR.pdf

work page 2024

[2] [1]

In our prior work we presented a methodology that automates the generation of smart contracts from BPMN models

1 BPMN Model to Smart Contract by Business Analyst Christian Gang Liu Faculty of Computer Science Dalhousie University Halifax, Canada Chris.Liu@dal.ca Peter Bodorik Faculty of Computer Science Dalhousie University Halifax, Canada Peter.Bodorik@dal.ca Dawn Jutla Sobey School of Business Saint Mary’s University Halifax, Canada Dawn.Jutla@gmail.com Abstract...

work page 2008

[3] [5]

Lorikeet: A Model-Driven Engineering Tool for Blockchain-Based Business Process Execution and Asset Management,

Tran, Q. Lu, and I. Weber, “Lorikeet: A Model-Driven Engineering Tool for Blockchain-Based Business Process Execution and Asset Management,” in Proc. 2018 Int. Conf. on Business Process Management, 1–5; https://api.semanticscholar.org/CorpusID:52195200

work page 2018

[4] [6]

CATERPILLAR: A Business Process Execution Engine on the Ethereum Blockchain,

O. López-Pintado, L. García-Bañuelos, M. Dumas, I. Weber, and A. Ponomarev, “CATERPILLAR: A Business Process Execution Engine on the Ethereum Blockchain,” Software Practice and Experience, 49(1). 2019, arXiv: arXiv:1808.03517. doi: 10.48550/arXiv.1808.03517

arXiv doi:10.48550/arxiv.1808.03517 2019

[5] [7]

Controlled flexibility in blockchain-based collaborative business processes,

O. López-Pintado, M. Dumas, L. García-Bañuelos, and I. Weber, “Controlled flexibility in blockchain-based collaborative business processes,” Information Systems, vol. 104, p. 101622, Feb. 2022, doi: 10.1016/j.is.2020.101622

arXiv 2022

[6] [14]

Decentralized collaborative business process execution using blockchain,

F. Loukil, K. Boukadi, M. Abed, and C. Ghedira-Guegan, “Decentralized collaborative business process execution using blockchain,” World Wide Web, vol. 24, no. 5, pp. 1645–1663, Sep. 2021, doi: 10.1007/s11280-021-00901-7

doi:10.1007/s11280-021-00901-7 2021

[7] [15]

Bianchini, V

Bagozi, D. Bianchini, V. De Antonellis, M. Garda, and M. Melchiori, “A Three-Layered Approach for Designing Smart Contracts. OTM 2019 Conf., Springer Int Publ, 440–457. doi: 10.1007/978-3-030-33246-4_28

doi:10.1007/978-3-030-33246-4_28 2019

[8] [16]

Integrated model‐driven engineering of blockchain applications for business processes and asset management

Qinghua Lu, An Binh Tran, Ingo Weber, Hugo O’Connor, Paul Rimba, Xiwei Xu, Mark Staples, Liming Zhu, and Ross Jeffery. Integrated model‐driven engineering of blockchain applications for business processes and asset management. Software: Practice and Experience 51, no. 5 (2021): 1059-1079

work page 2021