Pith. sign in

REVIEW 4 major objections 4 minor 43 references

On LLM-Assisted Generation of Smart Contracts from Business Processes

T0 review · 4 major / 4 minor · reviewed 2026-08-06 · deepseek-v4-flash

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

Pith's one-line read The paper claims that current LLMs can turn BPMN choreographies into mostly correct smart contracts, yet argues that anything below 100% correctness is unsafe for blockchains.

desk verdict A genuinely useful open benchmark for LLM-to-smart-contract generation, with solid-if-not-yet-fully-reported numbers that support the paper's core conclusion. read the letter →

arxiv 2507.23087 v1 pith:XNEYRNFT submitted 2025-07-30 cs.SE cs.AI

Fabian Stiehle , Hans Weytjens , Ingo Weber This is my paper · ORCID
classification cs.SEcs.AI
keywords LLMcodegenerationsmartcontractsBPMNchoreographiesprocessconformanceblockchain-basedexecutiontracereplaybenchmarkingSolidityautomatedevaluation
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

This paper establishes an automated, open benchmark for a specific task: given a BPMN 2.0 choreography model, can an LLM produce a Solidity smart contract that actually executes the process correctly? The authors run 165 realistic process models through seven LLMs, in one-shot and two-shot settings, and check each generated contract by replaying conforming and non-conforming traces against it. The best model, grok-3-beta, reaches an F1 macro of 0.918 with 100% compilability; Claude Sonnet 4 reaches 0.862 and GPT-4.1 0.797. Because a blockchain cannot tolerate a 2% error rate, let alone 8-20%, the paper concludes that standalone LLM generation falls short of the perfect reliability required, and recommends integrating LLMs into rule-based tools with formal verification rather than replacing them.

What carries the argument

The load-bearing mechanism is a trace-replay conformance oracle. The framework converts a BPMN choreography into an interaction net via Chorpiler, uses pm4py's playout routine to generate up to 2,500 conforming traces plus 50 manipulated non-conforming traces per process, then compiles and deploys the LLM-generated Solidity contract on a local EVM and replays the traces: a conforming trace must lead to the end event, and a non-conforming trace must be rejected somewhere. Precision, recall, and F1 macro are computed from that replay for each process, with a bitmask-encoding prompt pushing the LLM toward token-based execution. This oracle is what turns the question from 'does it compile?' into 'does it behave correctly?'.

What would settle it

Take one of the 165 process models, replace the 2,500-trace sampling cap with exhaustive enumeration of every possible execution path, and rerun the one-shot grok-3-beta benchmark: if any contract that scored F1 1.0 accepts a non-conforming trace that the larger trace set can now generate, or if the reported F1 drops, the paper's headline reliability estimate is too optimistic.

Watch

Extended reading notes

Core claim

The central claim, stated on the paper's own terms, is a measured capability gap. Current LLMs can transform executable choreography models into syntactically and functionally correct smart contracts most of the time, even on a diverse and realistic dataset, but not reliably enough for deployment. Concretely, the top-performing model achieves F1 macro 0.918 and 100% compilability in the one-shot setting, while open-source models lag behind; and because public blockchains are unforgiving, immutable, and exposed to exploit, the authors argue that scores below a reliable 100% are not suitable. They further state that this is a fundamental issue with current LLM architectures, not merely a prompt-tuning problem, and they show that two-shot prompting does not consistently improve results.

Load-bearing premise

The result stands or falls on whether the generated test traces are a correct ground truth: if the trace suite is wrong or incomplete, a correct contract can be marked incorrect, or an incorrect contract can look correct.

Editorial extensions

If this is right

  • Top proprietary LLMs generate contracts that compile almost always and pass the trace oracle in roughly 80-92% of checks on average per process.
  • Two-shot prompting does not consistently beat one-shot prompting, so simply adding examples is not a reliable route to production-quality contracts.
  • For blockchain process enactment, even a hypothetical 98% average F1 is presented as inadequate, so the required bar is 100% trace conformance rather than high accuracy.
  • A viable direction is to use LLMs to propose code or tests, then vet the output with formal specifications or theorem provers before deployment.
  • The open framework and data allow repeated benchmarking of future model versions and of hybrid rule-based/LLM tools.

Reading between the lines

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

  • I infer the benchmark's F1 numbers are probably conservative: the 2,500-trace cap and the manual removal of accidentally conforming traces mean the oracle covers only a subset of a model's behavior, so a contract that passes the sampled traces could still violate an unsampled execution path.
  • A testable extension would be to run the same framework with exhaustive reachability on small models; if F1 drops, the reported gap is even larger than the paper states.
  • The paper's own limitation note implies the manual trace-removal step is a source of measurement noise, and quantifying inter-rater agreement would let future work attach confidence intervals to the F1 scores.
  • I infer the framework could be repurposed to localize errors by reporting which construct (gateway, participant, or data condition) first fails on a trace, turning the benchmark from a score into a diagnostic for prompt or template design.
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.

Referee Report

4 major / 4 minor

Summary. The paper presents an open-source benchmarking framework that evaluates LLMs' ability to generate Solidity smart contracts from BPMN 2.0 choreography models. Using 165 pre-processed models from the SAP-SAM dataset, the framework generates conforming and non-conforming execution traces, prompts seven LLMs (proprietary and open-source) with one-shot and two-shot variants, compiles and deploys the generated contracts in a simulated EVM, replays the traces, and reports macro-F1 and compilability. The headline results are that the best models reach macro-F1 of 0.918 (grok-3-beta), 0.862 (claude-sonnet-4), and 0.797 (gpt-4.1) in the one-shot setting, with high compilability. The authors conclude that current LLMs generate correct contracts only 'most of the time' and, because blockchain applications require perfect reliability, recommend future work on integrating LLMs into rule-based generation tools rather than using LLM output directly.

Significance. If the results hold, this is a useful contribution: it is, to my knowledge, the first open, large-scale benchmark for LLM-based smart contract generation from process models, and it shifts evaluation from compilability-only checks to functional trace replay. The framework is concrete, the artifact is publicly available with an archived version, and the use of an independent trace oracle rather than LLM self-assessment is methodologically sound. The paper also provides cost, token, and gas data, which is valuable for practitioners. However, the central quantitative claims rest on the quality of the trace oracle and on a single run per configuration; the current manuscript does not report enough detail to make the headline F1 values reproducible or to separate them from oracle-label noise and stochastic variation.

major comments (4)
  1. [§5.2, footnote 15] The trace-generation footnote states that for models whose conforming-trace count exceeds the 2,500-trace search threshold, non-conforming traces that are actually conforming can be generated and 'must be manually removed.' The paper reports neither how many traces were removed (per model or in total), nor how the manual removal was performed, nor any inter-rater reliability check. This is load-bearing because these traces form the negative oracle: if a mislabeled trace remains, a correct contract that accepts it is scored as a false positive, deflating precision and F1, while a contract that incorrectly rejects it is scored as a true negative, inflating measured performance; the net effect depends on model behavior. Without these statistics, the headline F1 values in Table 2 are not independently reproducible from the paper alone.
  2. [§5.2, Table 2] Each model and prompt variant is evaluated in a single run with temperature set to 0, which the paper itself describes as only 'quasi-deterministic.' No confidence intervals, repeated runs, or per-case score distributions are reported. Given the paper's own citation that LLM outputs are non-deterministic [30], the differences among grok-3-beta (0.918), claude-sonnet-4 (0.862), and gpt-4.1 (0.797), as well as the 'most of the time' quantification, cannot be separated from run-to-run variation. Please report repeated runs, variance measures, or at least the distribution of per-process F1 scores.
  3. [§5.1] The pre-processing step inserts synthetic boolean conditions for all non-default outgoing XOR flows and arbitrarily sets a default flow when none is marked. This means that the evaluation of the 'data-based conditions' property, and the claim of a 'realistic and diverse dataset,' are based on models containing artificial decision logic rather than the original or recovered conditions. This limits the external validity of the F1 scores for real-world process models. The paper should state how many models had original conditions, discuss the impact of the synthetic conditions, and ideally report results separately for models with and without original gateway data.
  4. [§5.2] The prompts were refined in pre-runs conducted on sets of five to twenty process models, but the paper does not state whether those pre-run models were excluded from the final 165-model benchmark set. If there is overlap, the reported F1 values could be optimistically biased by prompt selection on the evaluation cases. Please clarify the disjointness of the pre-run and evaluation sets, or confirm that no pre-run model is included in the benchmark sample.
minor comments (4)
  1. [§5.3] The classification framework defines 'accepted' and 'rejected' traces but does not specify how the replay distinguishes between a transaction that reverts (and is therefore rejected) and a transaction that executes without a state change. Please clarify the replay semantics.
  2. [§6] The statement that the reliability issue 'cannot be resolved with current LLM architectures' is broader than the evidence from seven models and one prompting scheme; consider rephrasing to 'in our experiments' or 'based on current evidence' to avoid overgeneralization.
  3. [Table 2] Reporting F1 macro to three decimal places suggests a precision that is not supported by the single-run, manually filtered evaluation; consider rounding or adding variance measures.
  4. [§1 and §6] The phrase 'most of the time' is used without a quantitative definition; please tie it to the F1 values or define an explicit threshold.

Circularity Check

0 steps flagged · score 1.0 of 10

No significant circularity: the headline F1 scores are empirical measurements against an independent replay oracle, not quantities fitted from the data or derived from self-citations.

full rationale

The paper's central claims are empirical: seven LLMs are prompted to generate Solidity contracts from 165 process models, and the generated contracts are compiled, deployed, and replayed against conforming and non-conforming traces. The F1 scores in Table 2 are computed from trace-replay outcomes (true/false positives/negatives), not from any parameter fitted to the benchmark data. The only notable self-citation is Chorpiler [40], which is used as the trace-generation and encoding component. This is not a load-bearing circularity: Chorpiler is open-source, externally runnable code, and the traces are generated from the input process models via its interaction-net semantics rather than being derived from the LLM outputs under test. The paper also states that non-conforming trace generation can accidentally produce conforming traces that 'must be manually removed' (Section 5.3) and does not report counts or inter-rater reliability; this is an oracle-quality and reproducibility concern that could bias the reported F1 values, but it is not a case of a prediction reducing to its own input by construction. Prompt refinement on 5-20 model pre-runs is standard prompt development and does not make the reported held-out benchmark a fitted quantity, absent evidence that the pre-run models overlap the final 165. Overall, the derivation chain is self-contained: models are compared against an independent, replayed trace oracle, and the conclusion about insufficient reliability for blockchain deployment is an interpretation of those measured results, not a circular restatement.

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

The benchmark introduces no new domain entities. Its contributions are an evaluation workflow and a dataset, but the central numbers rest on several experimental design choices (trace caps, synthetic conditions, temperature) and on the Chorpiler oracle being the right ground truth.

free parameters (5)
  • trace_generation_threshold = 2500 conforming traces per process
    Section 5.2: cap on conforming traces per process; a search-threshold bound that makes loop-heavy models tractable but limits coverage.
  • non_conforming_traces_per_process = 50
    Section 5.2: number of manipulated traces replayed per model; chosen without sensitivity analysis.
  • temperature = 0
    Section 5.2: LLM sampling temperature set to 0 for quasi-determinism; tie-breaking can still introduce stochasticity.
  • boolean_decision_insertion = one boolean per non-default outgoing flow
    Sections 5.1 and 4.2: missing gateway conditions in SAP-SAM models were replaced with synthetic booleans, so data-based gateways are tested only on artificial conditions.
  • default_flow_assignment = first outgoing flow
    Section 5.1: when no default flow was marked, the first outgoing flow was set as default; arbitrary but necessary for executable models.
assumptions (5)
  • domain assumption The SAP-SAM subset of 165 models is representative of real BPMN choreography practice.
    Section 5: sample from SAP-SAM, whose construct distribution is claimed to match prior research; the sample itself is a non-random subset filtered by Chorpiler compilability and hand-inspected pre-processing.
  • domain assumption Chorpiler's interaction-net semantics and autonomous gateway execution define correct process conformance.
    Sections 4.2 and 5: traces are generated from Chorpiler's intermediate Petri net; the generated contract's correctness is judged solely against this oracle. If the oracle's semantics (e.g., the transactional 'as much progress as possible' logic from Ladleif et al. [24]) do not match user intent, the benchmark measures conformance to Chorpiler, not to the original process.
  • domain assumption Replaying a bounded set of conforming and non-conforming traces is a sufficient correctness check for generated smart contracts.
    Section 4: trace coverage is capped at 2500 conforming and 50 non-conforming traces per model, so the F1 score is an estimate, not an exhaustive verification.
  • domain assumption Randomly manipulated conforming traces are non-conforming, except where manually corrected.
    Section 5.3: the simulator 'randomly chosen and manipulated' traces; the paper admits this can accidentally produce conforming traces for loop-heavy models and that manual removal is required, without reporting the cleaning details.
  • standard math Macro F1 over cases is an appropriate aggregated correctness metric.
    Section 5.3: standard F1 and macro averaging over cases, balanced against the unbalanced trace counts.

how reviews work

0 comments
Cite this review

Pith. "Pith review of On LLM-Assisted Generation of Smart Contracts from Business Processes." pith.science (2026). https://pith.science/paper/XNEYRNFT

@misc{pith2026250723087,
  author       = {Pith},
  title        = {Pith review of: On LLM-Assisted Generation of Smart Contracts from Business Processes},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/XNEYRNFT}},
  note         = {Machine review of arXiv:2507.23087}
}
read the original abstract

Large language models (LLMs) have changed the reality of how software is produced. Within the wider software engineering community, among many other purposes, they are explored for code generation use cases from different types of input. In this work, we present an exploratory study to investigate the use of LLMs for generating smart contract code from business process descriptions, an idea that has emerged in recent literature to overcome the limitations of traditional rule-based code generation approaches. However, current LLM-based work evaluates generated code on small samples, relying on manual inspection, or testing whether code compiles but ignoring correct execution. With this work, we introduce an automated evaluation framework and provide empirical data from larger data sets of process models. We test LLMs of different types and sizes in their capabilities of achieving important properties of process execution, including enforcing process flow, resource allocation, and data-based conditions. Our results show that LLM performance falls short of the perfect reliability required for smart contract development. We suggest future work to explore responsible LLM integrations in existing tools for code generation to ensure more reliable output. Our benchmarking framework can serve as a foundation for developing and evaluating such integrations.

Figures

Figures reproduced from arXiv: 2507.23087 by the authors.

Figure 1
Figure 1. Main components, services and data of the benchmarking framework [PITH_FULL_IMAGE:figures/full_fig_p006_1.png] view at source ↗
Figure 2
Figure 2. Process of our benchmark experiment: We pre-process the raw model data [PITH_FULL_IMAGE:figures/full_fig_p010_2.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

43 extracted references · 33 canonical work pages

  1. [30]

    ACM Transactions on Software Engineering and Methodology34(2), 1–28 (2025)

    Ouyang, S., Zhang, J.M., Harman, M., Wang, M.: An empirical study of the non-determinism of chatgpt in code generation. ACM Transactions on Software Engineering and Methodology34(2), 1–28 (2025)

    work page 2025

  2. [1]

    In: Proceedings of the 18th Innovations in Software Engineering Conference

    Alam, M.T., Goswami, S., Singh, K., Halder, R., Maiti, A., Banerjee, S.: Solgen: Secure smart contract code generation using large language models via masked prompting. In: Proceedings of the 18th Innovations in Software Engineering Conference. pp. 1–11 (2025)

    work page 2025

  3. [2]

    Ali, M., Fromm, M., Thellmann, K., et al.: Tokenizer choice for LLM training: Negligible or crucial? In: Findings of the Association for Computational Linguistics: NAACL 2024. pp. 3907–3924 (2024)

    work page 2024

  4. [3]

    Addison-Wesley Professional (2025)

    Bass, L., Lu, Q., Weber, I., Zhu, L.: Engineering AI Systems: Architecture and DevOps Essentials. Addison-Wesley Professional (2025)

    work page 2025

  5. [4]

    In: International Conference on Bridging the Gap between AI and Reality

    Belzner, L., Gabor, T., Wirsing, M.: Large language model assisted software engineering: prospects, challenges, and a case study. In: International Conference on Bridging the Gap between AI and Reality. pp. 355–374. Springer (2023)

    work page 2023

  6. [5]

    In: International Conference on Process Mining

    Berti, A., Kourani, H., van der Aalst, W.M.: PM-LLM-Benchmark: Evaluating large language models on process mining tasks. In: International Conference on Process Mining. pp. 610–623. Springer (2024)

    work page 2024

  7. [6]

    Software Impacts17, 100556 (2023)

    Berti, A., van Zelst, S., Schuster, D.: PM4Py: A process mining library for python. Software Impacts17, 100556 (2023)

    2023

  8. [7]

    Brynjolfsson, E., Li, D., Raymond, L.R.: The productivity effects of gen- erative AI: Evidence from a field experiment with GitHub Copilot (2023), https://mit-genai.pubpub.org/pub/v5iixksv/release/2, accessed 2025-06-07

    work page 2023

Show all 43 references
  1. [8]

    ACM Transactions on Software Engineering and Methodology (2025)

    Burgueño, L., Di Ruscio, D., Sahraoui, H., Wimmer, M.: Automation in model-driven engineering: A look back, and ahead. ACM Transactions on Software Engineering and Methodology (2025)

    2025

  2. [9]

    ACM transactions on intelligent systems and technology15(3), 1–45 (2024)

    Chang, Y., Wang, X., Wang, J., Wu, Y., Yang, L., Zhu, K., Chen, H., Yi, X., Wang, C., Wang, Y., et al.: A survey on evaluation of large language models. ACM transactions on intelligent systems and technology15(3), 1–45 (2024)

    2024

  3. [10]

    In: Future of Information and Communication Conference

    Chatterjee, S., Ramamurthy, B.: Efficacy of various large language models in generating smart contracts. In: Future of Information and Communication Conference. pp. 482–500. Springer (2025)

    2025

  4. [11]

    arXiv preprint arXiv:2107.03374 (2021)

    Chen, M., Tworek, J., Jun, H., Yuan, Q., Pinto, H.P.D.O., Kaplan, J., Edwards, H., Burda, Y., Joseph, N., Brockman, G., et al.: Evaluating large language models trained on code. arXiv preprint arXiv:2107.03374 (2021)

    2021 arXiv

  5. [12]

    In: International Conference on Software Analysis, Evolution and Reengineering (SANER)

    De Vito, G., D’Amici, D., Izzo, F., Ferrucci, F., Di Nucci, D.: LLM-based generation of solidity smart contracts from system requirements in natural language: The AstraKode case. In: International Conference on Software Analysis, Evolution and Reengineering (SANER). pp. 170–18...

    2025

  6. [13]

    Decker, G., Weske, M.: Local enforceability in interaction Petri nets. In: BPM. LNCS, vol. 4714, pp. 305–319. Springer, Cham (2007)

    2007

  7. [14]

    Dong, Q., Li, L., Dai, D., Zheng, C., Ma, J., Li, R., Xia, H., Xu, J., Wu, Z., Liu, T., Chang, B., Sun, X., Li, L., Sui, Z.: A survey on in-context learning (2024), https://arxiv.org/abs/2301.00234

    2024 arXiv

  8. [15]

    IEEE Software (2025)

    Gao, S., Liu, W., Zhu, J., Dong, X., Dong, J.: BPMN-LLM: Transforming bpmn models into smart contracts using large language models. IEEE Software (2025)

    2025

  9. [16]

    In: BPM, pp

    García-Bañuelos, L., Ponomarev, A., Dumas, M., Weber, I.: Optimized Execution of Business Processes on Blockchain. In: BPM, pp. 130–146. Springer, Cham (2017)

    2017

  10. [17]

    In: International Conference on Business Process Management

    Grohs, M., Abb, L., Elsayed, N., Rehse, J.R.: Large language models can accomplish business process management tasks. In: International Conference on Business Process Management. pp. 453–465. Springer (2023)

    2023

  11. [18]

    arXiv preprint arXiv:2504.13217 (2025)

    Haase, J., Klessascheck, F., Mendling, J., Pokutta, S.: Sustainability via LLM right-sizing. arXiv preprint arXiv:2504.13217 (2025)

    2025 arXiv

  12. [19]

    In: International Conference on Advanced Information Systems Engineering

    Hörner, L.F.: Towards an LLM-based conversational framework for business process modeling: Research approach and preliminary results. In: International Conference on Advanced Information Systems Engineering. pp. 286–293. Springer (2025)

    2025

  13. [20]

    ACM Transactions on Software Engineering and Methodology (2024)

    Huang, D., Zhang, J.M., Bu, Q., Xie, X., Chen, J., Cui, H.: Bias testing and mitigation in LLM-based code generation. ACM Transactions on Software Engineering and Methodology (2024)

    2024

  14. [21]

    In: 2023 5th Conference on Blockchain Research & Applications for Innovative Networks and Services (BRAINS)

    Karanjai, R., Li, E., Xu, L., Shi, W.: Who is smarter? an empirical study of ai-based smart contract creation. In: 2023 5th Conference on Blockchain Research & Applications for Innovative Networks and Services (BRAINS). pp. 1–8. IEEE (2023)

    2023

  15. [22]

    In: International Conference on Business Process Management

    Klievtsova, N., Benzin, J.V., Kampik, T., Mangler, J., Rinderle-Ma, S.: Conversa- tional process modelling: state of the art, applications, and implications in practice. In: International Conference on Business Process Management. pp. 319–336. Springer (2023)

    2023

  16. [23]

    In: Business Process Management

    Kubrak, K., Botchorishvili, L., Milani, F., Nolte, A., Dumas, M.: Explanatory capabilities of large language models in prescriptive process monitoring. In: Business Process Management. pp. 403–420. Springer Nature Switzerland, Cham (2024)

    2024

  17. [24]

    In: BPM, vol

    Ladleif, J., Weske, M., Weber, I.: Modeling and Enforcing Blockchain-Based Choreographies. In: BPM, vol. 11675, pp. 69–85 (2019)

    2019

  18. [25]

    arXiv preprint arXiv:2505.08542 (2025)

    Luo, H., Lin, Y., Yan, X., Hu, X., Wang, Y., Zeng, Q., Wang, H., Jiang, J.: Guiding LLM-based smart contract generation with finite state machine. arXiv preprint arXiv:2505.08542 (2025)

    2025 arXiv

  19. [26]

    Monti, F., Leotta, F., Mangler, J., Mecella, M., Rinderle-Ma, S.: Nl2processops: towards LLM-guided code generation for process execution. In: BPM. pp. 127–143 (2024)

    2024

  20. [27]

    Muehlen, M.z., Recker, J.: How Much Language Is Enough? Theoretical and Practical Use of the Business Process Modeling Notation, pp. 429–443. Springer (2013)

    2013

  21. [28]

    In: Computers, Software, and Applications Conference (COMPSAC)

    Napoli, E.A., Barbàra, F., Gatteschi, V., Schifanella, C.: Leveraging large language models for automatic smart contract generation. In: Computers, Software, and Applications Conference (COMPSAC). pp. 701–710. IEEE (2024)

    2024

  22. [29]

    here’s the story you haven’t heard

    O’Donnell, J., Crownhart, C.: We did the math on AI’s energy footprint. here’s the story you haven’t heard. MIT Technology Review (May 2025)

    2025

  23. [31]

    In: ICPM

    Pasquadibisceglie, V., Appice, A., Malerba, D.: LUPIN: A LLM approach for activity suffix prediction in business process event logs. In: ICPM. pp. 1–8 (2024)

    2024

  24. [32]

    Communications of the ACM68(2), 96–105 (2025) LLMs for Smart Contract Generation from Business Processes 15

    Pearce, H., Ahmad, B., Tan, B., Dolan-Gavitt, B., Karri, R.: Asleep at the keyboard? Assessing the security of GitHub Copilot’s code contributions. Communications of the ACM68(2), 96–105 (2025) LLMs for Smart Contract Generation from Business Processes 15

    2025

  25. [33]

    Pfeiffer, P., Rombach, A., Majlatow, M., Mehdiyev, N.: From theory to practice: Real-world use cases on trustworthy LLM-driven process modeling, prediction and automation (2025), https://arxiv.org/abs/2506.03801

    2025 arXiv

  26. [34]

    Advances in neural information processing systems33, 20601–20611 (2020)

    Roziere, B., Lachaux, M.A., Chanussot, L., Lample, G.: Unsupervised translation of programming languages. Advances in neural information processing systems33, 20601–20611 (2020)

    2020

  27. [35]

    arXiv preprint arXiv:2110.06773 (2021)

    Roziere, B., Zhang, J.M., Charton, F., Harman, M., Synnaeve, G., Lample, G.: Leveraging automated unit tests for unsupervised code translation. arXiv preprint arXiv:2110.06773 (2021)

    2021 arXiv

  28. [36]

    PLOS Digital Health2(11), 1–3 (11 2023)

    Smith, A.L., Greaves, F., Panch, T.: Hallucination or confabulation? Neuroanatomy as metaphor in large language models. PLOS Digital Health2(11), 1–3 (11 2023)

    2023

  29. [37]

    In: Process Mining Workshops at ICPM 2022

    Sola, D., Warmuth, C., Schäfer, B., Badakhshan, P., Rehse, J., Kampik, T.: SAP Signavio academic models: A large process model dataset. In: Process Mining Workshops at ICPM 2022. LNBIP, vol. 468, pp. 453–465. Springer (2022)

    2022

  30. [38]

    In: In- nov8BPM’24: International Workshop on Managing Process Innovation and Value Creation in the Era of Digital Transformation at BPM’24 (2024)

    Stiehle, F., Klessascheck, F., Kjäer, M., Weber, I.: Business in the age of platform economics: Managing decentralised business processes beyond blockchain. In: In- nov8BPM’24: International Workshop on Managing Process Innovation and Value Creation in the Era of Digital Trans...

    2024

  31. [39]

    In: BPM: Forum

    Stiehle, F., Weber, I.: Blockchain for business process enactment: a taxonomy and systematic literature review. In: BPM: Forum. LNBIP, vol. 459, pp. 5–20 (2022)

    2022

  32. [40]

    Stiehle, F., Weber, I.: Process channels: A new layer for process enactment based on blockchain state channels. In: BPM. pp. 198–215. Springer (2023)

    2023

  33. [41]

    Advances in neural information processing systems30(2017)

    Vaswani, A., Shazeer, N., Parmar, N., et al.: Attention is all you need. Advances in neural information processing systems30(2017)

    2017

  34. [42]

    In: International Conference on Business Process Management

    Vidgof, M., Bachhofner, S., Mendling, J.: Large language models for business process management: Opportunities and challenges. In: International Conference on Business Process Management. pp. 107–123. Springer (2023)

    2023

  35. [43]

    Advances in Computer Sciences7(1), 1–7 (2024)

    Wong, E.: Comparative analysis of open source and proprietary large language models: Performance and accessibility. Advances in Computer Sciences7(1), 1–7 (2024)

    2024

Pith tools

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