{"id":"19e48c17-32b8-4259-a4a8-349cd5cf931c","arxiv_id":"2505.22612","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A methodology and proof-of-concept tool are proposed to transform BPMN models with DMN decision logic into blockchain smart contracts, authored by business analysts rather than developers.","lead":"This paper describes how a business analyst can model a blockchain application in BPMN and DMN and then use the authors' TABS+R tool to generate smart contracts without a developer. The significance is a lower-skilled path to blockchain automation, but the paper provides no released tool, generated code, or evaluation to back the claim.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"No significant objection identified","rationale":"The reader's weakest assumption points to the expressiveness of DMN and the missing support for FEEL. I agree that this is the central risk, but the more precise and more damaging mechanism is stated in Section V: the paper itself removes task logic from the generated contract by having the BA or an operator execute tasks off-chain and only record document CIDs on-chain. Thus, even the 'simple decision table' may not be transformed into executable contract logic; it might only influence which off-chain action is taken next. This makes the no-developer claim structurally unsupported rather than merely under-evaluated. However, the paper is a proof-of-concept proposal, not a false empirical claim; it could become valid if the artifact is released and an end-to-end transformation is shown. The reader's CONDITIONAL verdict already requires exactly that. I would keep the verdict unchanged, with the condition being the release of TABS+R and a concrete demonstration that DMN decision rules compile to on-chain code, including at least one nontrivial FEEL expression or a convincing argument that the supported subset covers realistic business logic.","tokens_in":8474,"tokens_out":3494,"duration_ms":41442,"concrete_test":"Run TABS+R on the Section V use case (the combine-harvester example with the insurance decision table) and inspect both the DMN XML exported from the Camunda/BPMN.io editor and the generated smart contract source for EVM or HLF. Verify that the insurance rule (quote <= 0.15 * price) appears as actual on-chain branching logic, e.g., a require or if statement in the generated method, and that no task method is hand-written, stubbed, or delegated to an off-chain operator. If the generated contract merely records CIDs and the abort/recovery path is triggered by an external manual action, then the no-developer claim fails even for this simple example.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim is that a business analyst who can express requirements in BPMN+DMN can use TABS to generate deployable smart contracts without developer assistance. The load-bearing step is the transformation of DMN business rules into executable smart contract code, but this step is never demonstrated. Section IV states 'currently we only support simple decision tables' and dismisses FEEL support with 'we do not foresee design challenges', without giving transformation rules, generated code, or an evaluation. More seriously, Section V undercuts the claim: 'when task executions can be performed off-chain, the task script code does not need to be provided on-chain' and '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.' For the paper's own use cases, the contract is limited to exchanging document CIDs and recording outcomes; the DMN decision table only selects an abort path. If TABS does not actually compile DMN tables or FEEL into on-chain branching logic, then a BA cannot generate a useful smart contract for any nontrivial task without a developer, and the headline claim collapses. This is a missing-evidence gap rather than an internal contradiction; the architecture could be extended, but the paper does not show that extension.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":8667,"tokens_out":2445,"duration_ms":27270,"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":[{"comment":"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":"Section IV, FEEL paragraph"},{"comment":"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":"Section V, off-chain task execution"},{"comment":"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.","section":"Section II and Section VII"}],"minor_comments":[{"comment":"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.\"","section":"Section IV"},{"comment":"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":"References"},{"comment":"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.","section":"Section III.B"}],"recommendation":"major_revision","confidential_remarks":"The paper is within the scope of the journal, but its length and level of evidence are currently more appropriate for a workshop or a position paper. The authors should be encouraged to provide a concrete demonstration of the DMN-to-code transformation—ideally including transformation rules, generated code for the running example, and a minimal evaluation—or to explicitly reframe the paper as a research agenda rather than a validated method."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","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.\n\nWhat'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.\n\nThe 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.\n\nWho 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.\n\nRecommendation: 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.","headline":"A plausible but unproven extension of the authors' TABS pipeline; the DMN-to-code step is asserted, not demonstrated.","tokens_in":9202,"tokens_out":1872,"would_cite":false,"duration_ms":22584,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A business analyst alone can turn BPMN and DMN models into deployable smart contracts.","keywords":["smart contract generation","BPMN","DMN","decision tables","business analyst","blockchain","model-driven engineering","TABS"],"falsifier":"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.","tokens_in":8250,"feed_emoji":"📜","tokens_out":9164,"duration_ms":101362,"temperature":0.7,"pith_summary":"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.","feed_headline":"BPMN and DMN become smart contracts without a developer","feed_subtitle":"A business analyst's BPMN and DMN diagrams become deployable blockchain contracts.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Supplies the base TABS methodology for transforming BPMN flow control into smart contracts, which this paper extends with DMN.","marker":"[10]"},{"why":"Adds support for nested collaborative long-running transactions, a feature the BA-only workflow inherits.","marker":"[11]"},{"why":"Adds smart-contract repair and upgrade, so generated contracts can be corrected or updated without starting over.","marker":"[12]"},{"why":"Defines BPMN, DMN, and FEEL, the standards the BA uses to express process flow and business logic.","marker":"[9]"},{"why":"Provides the content-addressed off-chain storage mechanism whose content identifiers are signed and stored on-chain to verify documents.","marker":"[13]"},{"why":"Documents the DMN and FEEL implementation in a graphical editor used to construct the decision table in the tool demonstration.","marker":"[18]"}],"fun_headline_variants":["Business analysts now generate smart contracts from BPMN and DMN","No developer required: BPMN and DMN to smart contracts","Automated smart contracts: BPMN and DMN without programmers","Turning BPMN and DMN into smart contracts—no coding needed","From BPMN diagrams to smart contracts: the BA's shortcut"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["Business analysts now generate smart contracts from BPMN and DMN","No developer required: BPMN and DMN to smart contracts","Automated smart contracts: BPMN and DMN without programmers","Turning BPMN and DMN into smart contracts—no coding needed","From BPMN diagrams to smart contracts: the BA's shortcut"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000438,"raw_usage":{"total_tokens":2231,"prompt_tokens":958,"completion_tokens":1273,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":574,"completion_tokens_details":{"reasoning_tokens":1181}},"tokens_in":574,"tokens_out":1273,"duration_ms":8495,"temperature":1.0,"reasoning_tokens":1181,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-07T13:02:44.970044+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Adds smart-contract repair and upgrade, so generated contracts can be corrected or updated without starting over."}],"review_version":1}