Jira Is Turing-Complete: Building a Minsky Machine in Atlassian Automation
For years, engineering folklore has suggested that Jira—Atlassian's ubiquitous project-tracking tool—is Turing-complete. While many have vaguely pointed to its automation features as evidence, few have provided a formal reduction to prove it.
Recently, Nicolas Seriot provided that proof by demonstrating how to build a Minsky register machine within Jira's automation framework. This discovery transforms Jira from a simple ticket tracker into a theoretical computer, explaining why complex Jira configurations often feel like programming—because, in a formal sense, they are.
The Computational Model: The Minsky Machine
To prove Turing-completeness, Seriot utilizes the Minsky register machine. A Minsky machine is a theoretical model of computation that requires only two unbounded counters (registers) and a finite set of labeled instructions. The only operations allowed are:
- Increment (
INC r; goto S): Increment register r, then move to state S. - Decrement/Branch (
DEC r; if r == 0 goto S else goto S'): Decrement register r. If the register was already zero, move to state S; otherwise, move to state S'.
Marvin Minsky proved in 1967 that this minimal model is Turing-complete. Therefore, if these operations can be mapped onto Jira's functionality, Jira is also Turing-complete.
Mapping Minsky to Jira
Seriot's reduction maps the theoretical components of a Minsky machine to specific Jira entities:
| Minsky Machine | Jira Implementation |
|---|---|
| Register A | Count of linked issues of type Bug |
| Register B | Count of linked issues of type Task |
| Program Counter | Status of a single Epic issue |
| Dispatch Table | Jira Automation rules (one per instruction state) |
| Clock | Automation-triggered transitions or external re-triggering |
In this model, the status of an Epic serves as the current instruction pointer. Automation rules inspect the counts of linked issues (the registers) and determine the next status (the next state). Incrementing and decrementing are handled by creating or deleting linked issues, while conditional branching is achieved via JQL-conditioned rules.
Practical Implementation: Adding Two Numbers
To demonstrate the proof, Seriot implements a simple addition program (adding register A into register B). The setup requires a Jira workflow with statuses such as BACKLOG, TODO, DEV, and PROD.
- State
TODO(DEC A): If at least one linked Bug exists, delete one Bug and transition the Epic toDEV. Otherwise, transition the Epic toPROD(halt). - State
DEV(INC B): Create a new Task, link it to the Epic, and transition the Epic back toTODO.
By initializing the Epic with 2 Bugs (A=2) and 3 Tasks (B=3) and transitioning it to TODO, the system cascades through the rules until it reaches PROD. The final result is 0 Bugs and 5 Tasks, effectively calculating 2 + 3 = 5.
Scaling Complexity: Fibonacci and the "Convert" Shortcut
While the addition example proves the theory, Jira's automation language offers a Convert Issue Type action that simplifies the process. Converting a Bug to a Story is functionally equivalent to a DEC Bug followed by an INC Story.
Using this shortcut, Seriot implemented a Fibonacci sequence generator (A, B) → (B, A+B) using only three states (TODO, QA, and DEV) and three registers (Bugs, Tasks, and Stories).
One practical limitation is Jira Cloud's chain-depth cap (typically 10 triggers), which prevents infinite loops. However, as Seriot notes, this is a physical limitation of the hosting environment rather than a theoretical limitation of the language. A human operator can simply re-trigger the Epic to provide the next "clock tick," maintaining the reduction's validity.
Community Perspectives: The "Turing Tarpit"
The revelation that Jira is Turing-complete sparked significant discussion among developers. Many noted that this explains why Jira often feels like "programming in assembly" to achieve basic goals.
One commenter, @lmm, joked that this explains why it is often impossible to tell if a given Jira operation will ever halt—a direct reference to the Halting Problem.
Other insights from the community include:
"If you can make Jira an order of magnitude easier to use for yourself than for the people pushing it, suddenly the script flips and Jira is something you push to protect yourself." — @Buttons840
"It's actually easy to be Turing complete. It's a feat for a system to be non-Turing complete and be 'complex'." — @itemize123
Conclusion
By reducing a Minsky machine to Jira Automation, we can formally conclude that Jira is Turing-complete. While few developers will actually use Jira to write software, the proof highlights a fundamental truth about modern enterprise software: when a tool's automation capabilities grow sufficiently complex, they inevitably become a programming language—often one that is unintentionally difficult to use.