tok: A Textual BPMN/DMN Syntax for Humans and AI

Business process modeling has long depended on graphical tools. The XML storage formats of BPMN and DMN are machine-friendly but quite unwieldy for humans and large language models. A new paper proposes tok to change this: it expresses BPMN 2.0.2 process models and DMN 1.5 decision models in plain text, with a single engine that simultaneously performs standard validation, compiles to XML with auto-generated diagrams, and serves language model applications via the Model Context Protocol.

What tok is: an alternative concrete syntax for BPMN/DMN

The paper classifies tok as an alternative concrete syntax for the BPMN and DMN metamodels. This positioning is key — tok is not a new standard, nor a proprietary DSL, but a textual representation built on the same metamodel. This means tok documents can be strictly validated against BPMN 2.0.2 and DMN 1.5, rather than merely "looking like" they conform.

The engineering trade-offs are equally clear: a tok document is handled by a single engine, with validation, compilation, and diagram generation completed in one pipeline. For teams accustomed to managing process assets with Git, plain text means diffable, reviewable, and mergeable; for language models, plain text means fewer tokens and a smaller surface for errors.

Concrete syntax versus abstract syntax is a core distinction in the modeling language field. The abstract syntax (such as the BPMN metamodel) defines which elements a model can contain and what relationships are allowed between them, independent of how it is written or drawn; the concrete syntax is the actual way this abstract structure is presented in a given medium. BPMN's common concrete syntax is the diagram, DMN's is decision tables and expressions, and their XML serialization can also be viewed as a machine-oriented concrete syntax. The same abstract syntax can have multiple concrete syntaxes that are losslessly interconvertible. tok's positioning is precisely to add a new concrete syntax oriented toward text and language models, so it need not redefine semantics — it only needs to guarantee strict alignment with the metamodel, and validation can therefore be performed directly against the specification constraints of BPMN 2.0.2 and DMN 1.5.

Model Context Protocol (MCP) is a protocol proposed and open-sourced by Anthropic in late 2024 to establish a standardized invocation interface between language model applications and external tools and data sources. It abstracts capability providers as servers and host applications (such as IDE plugins, desktop clients, and agent frameworks) as clients, with the two sides interacting through declarative tool lists and structured request-response, thereby avoiding writing separate integration code for each model application. For tok, exposing validation and compilation capabilities through MCP means any agent supporting the protocol can directly call the tok engine without implementing BPMN/DMN parsing itself — this is also the infrastructure prerequisite that makes the paper's "single checker tool" experiment viable.

Measured data: fewer tokens, more accurate error detection

The comparison figures in the paper are worth examining one by one. On 893 BPMN XML files exported by 37 tools, tok models require 2.2 times fewer tokens than even the smallest of those XML files, and 7.7 times fewer than the original export form. This gap is not a fine-tuning-level difference — it directly changes whether long process models can fit into the context window.

On validation capability, against 1,411 injected faults, the tok checker identifies 98.2%, compared with 85.8% for the combination of XML Schema and bpmnlint. This shows that the textual syntax does not trade rigor for conciseness; it actually performs better at fault detection.

XML Schema and bpmnlint represent two different validation approaches. XML Schema (XSD) is a W3C standard that, based on the XSD provided by BPMN 2.0.2, constrains the element structure, order, types, and cardinality of XML documents. It is syntax-level validation that can catch structural errors but does not understand semantic rules — for example, whether a gateway is missing branch conditions or whether a process has unreachable nodes. bpmnlint, by contrast, is a community-maintained BPMN static rule checker whose configurable rule sets cover semantic and stylistic issues such as naming conventions and connection validity, but its rule coverage is limited and its extensions depend on plugins. Combining the two is common practice today, and its 85.8% detection rate reflects precisely the ceiling of this "structural validation + limited rules" combination. tok unifies metamodel constraints and semantic rules within a single engine, which is the structural reason for its higher detection rate.

Can language models write tok directly?

The paper designs two sets of experiments. The first has four language models that had never previously encountered tok write tok using only a one-page reference document: on 87 process descriptions from two datasets, the valid tok generation rate was 85.7% to 100%, while the corresponding BPMN XML could be written for every description. The strongest model used 25% and 19% fewer tokens writing tok than writing BPMN XML.

The second configures the model as an agent with a lean skill and a single checker tool: the valid tok generation rate rises to 97.6% to 100%, and the strongest model's token savings are 21% and 14%. There is an easily overlooked detail here — if the skill is designed so that the model reads the reference document through a tool, the token overhead is 1.7 to 2.8 times that of the lean skill. In other words, putting reference material into the context is more economical than having the model repeatedly call tools to look it up, which has direct reference value for agent prompt engineering.

From logs back to models: closed-loop validation

The paper also conducts a round-trip test: 47 event logs are simulated from public models, of which 44 can be fitted back to their source models, and tok can import every model discovered from these logs. The significance of this test is to confirm that tok is not only "able to write" but can also hold up in the pipeline of process mining and model reconstruction.

A few observations

tok's value lies not in replacing graphical modeling, but in providing process assets with an underlying representation better suited to version control and to reading and writing by large models. The 2.2x to 7.7x token gap, the 98.2% versus 85.8% fault detection rate, and native MCP support form a coherent path from manual modeling to automated agent processing. It should be noted that current validation is concentrated on the paper's two self-built datasets and public models; tok's performance in large enterprise process repositories, and the willingness of the multi-tool ecosystem to adopt it, remain to be seen.

For teams integrating process modeling into AI workflows, the "lean skill + single checker tool" pattern proposed by tok may be more worth borrowing than the syntax itself.

One-line Summary

tok expresses BPMN/DMN in plain text, saving tokens, detecting errors more accurately, and natively serving language models.

Paragraph Summary

tok, proposed in the paper, is an alternative concrete syntax for the BPMN 2.0.2 and DMN 1.5 metamodels, replacing unwieldy XML with plain text to express process and decision models, with a single engine performing standard validation, compiling to XML with auto-generated diagrams, and serving language model applications via MCP. Measurements show that on 893 BPMN XML files, tok requires 2.2 times fewer tokens than the smallest XML and 7.7 times fewer than the original export form; it detects 98.2% of 1,411 injected faults, higher than the 85.8% of XML Schema plus bpmnlint. Four models encountering tok for the first time can generate 85.7% to 100% valid tok from a one-page reference document, rising to 97.6% to 100% with a checker tool configured. In round-trip testing, 44 of 47 logs can be fitted back to their source models. The authors argue that tok's value lies in providing process assets with an underlying representation suited to version control and to reading and writing by large models, though its performance in enterprise process repositories and the multi-tool ecosystem remains to be seen.