Jira IS Turing-Complete

Nicolas Seriot
Computation > Jira is Turing-Complete

Jira is Turing-Complete

Building a Minsky Machine in Atlassian Automation
22nd May 2026
Engineering folklore holds that Jira (Atlassian's project-tracking tool) is Turing-complete.
Existing claims point vaguely at automation features without exhibiting a reduction.
This article supplies a proof, with setup instructions and execution trace.
Mapping the Computational Model
A Minsky register machine needs only two unbounded counters and a finite set of labeled instructions:

INC r; goto S
DEC r; if r == 0 goto S else goto S'

Or, in plain English:

increment register R, then goto some state S
decrement register R, if R == 0 goto zero-state S, else goto nonzero-state S'

A Minsky program that adds register A into register B looks like:
1. DEC A; if A == 0 goto 3 else goto 2
2. INC B; goto 1
3. HALT

Minsky proved this model Turing-complete (1967).
Exhibiting it in Jira's automation language therefore establishes the reduction.
Here is how the model maps onto Jira:

Minsky Machine
Jira

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 past chain caps

The Epic's status encodes the current instruction.
Automation rules inspect the linked-issue counts and decide the next status.
INC and DEC are implemented as issue creation and deletion on the appropriate linked-issue type.
Conditional branching is implemented as a JQL-conditioned rule.
Implementing Addition
Here is a minimal working implementation using one Epic, five linked issues, and one Automation rule per instruction state (Space Settings > Automation).
1. Create Workflow
Create a Jira Workflow with statuses initial state BACKLOG, then TODO, DEV and PROD.
Any state can transition to any other.
Create an Epic in status BACKLOG.
2. Create Rule for TODO
DEC A; if A=0 halt, else goto DEV.

Trigger: Epic status changed to TODO.
If at least one linked Bug exists: delete one Bug, transition Epic to DEV.
Else: transition Epic to PROD (halt).

3. Create Rule for DEV
INC B; goto TODO.

Trigger: Epic status changed to DEV.
Create a new Task, link it to the Epic.
Transition Epic to TODO.

Both rules have "Allow rule to trigger other rules" enabled.
The screenshot below shows the two rules wired into the Epic's workflow.

4. Init Registers
Link 2 Bugs (A=2) and 3 Tasks (B=3) to the Epic.
5. Bootstrap the Machine.
Transition the Epic to TODO to start the cascade. Five transitions:
(2,3) TODO →
(1,3) DEV →
(1,4) TODO →
(0,4) DEV →
(0,5) TODO →
(0,5) PROD

Recorded on a real *.atlassian.net instance.
The Epic lands in PROD with 0 Bugs and 5 Tasks linked. We've just added 2 + 3 = 5.
Fibonacci in Three States
The reduction above suffices to prove Turing-completeness.
In addition to that, Jira's automation language can simplify Minsky operations.
Convert Issue Type changes an issue's type instantly: Bug → Story, Story → Task, and so on.
CONVERT is expressible as DEC + INC. It doesn't extend Jira's computational power, but it shrinks the dispatch table dramatically for any move-loop, making non-trivial programs tractable.
Fibonacci as (A, B) → (B, A+B) collapses to three states with three registers (A=Bug, B=Task, C=Story), using TODO, QA (add it to the workflow), and DEV as the three instruction states:
TODO:
if any linked Task exists:
CONVERT Task → Story
INC Bug
transition to TODO
else:
transition to QA

QA:
if any linked Bug exists:
CONVERT Bug → Task
transition to QA
else:
transition to DEV

DEV:
if any linked Story exists:
CONVERT Story → Bug
transition to DEV
else:
transition to TODO

Initial state A=1, B=1, C=0. The sequence 1, 1, 2, 3, 5, 8, 13, … appears in B (Task count).
Unlike the addition machine, the Fibonacci machine has no halt state.
It runs until Jira Cloud's chain-depth cap of 10 triggers, at which point the operator re-triggers the Epic to continue.
A single status edit restarts the cascade.
The reduction still holds, the human just supplies the next clock tick.
Jira Data Center exposes the same as automation.rule.execution.timeout and related, configurable properties.
Conclusion
Jira's automation language can encode a two-counter machine given unbounded issue creation and rule execution.
Every physical computer is finite, so Jira Cloud's finite quotas do not refute the construction.
Under that standard convention, Jira is Turing-complete.
So, if complex Jira automations feel like programs, it is because they literally are.

Engineering folklore suggests that Jira, Atlassian's project-tracking tool, possesses Turing-complete capabilities, a claim supported by a formal reduction from the Minsky Machine model. This article provides a proof demonstrating this computational power by mapping the architecture of the Minsky machine onto the features of Jira's automation language. The Minsky machine is defined by two unbounded counters and a finite set of instructions involving incrementing or decrementing registers, along with conditional branching based on register values. The proof establishes a mapping between these abstract computational elements and Jira components.

The mapping involves assigning the Minsky registers to Jira entities: Register A corresponds to the count of linked issues of type Bug, Register B corresponds to the count of linked issues of type Task, the Program Counter is encoded by the status of a single Epic issue, the Dispatch Table is implemented via Jira Automation rules, and the Clock is represented by automation-triggered transitions or external re-triggering. The Epic's status serves to encode the current instruction state, and the automation rules inspect the linked issue counts to determine the next state. The basic operations of increment and decrement are realized through the creation and deletion of linked issues, while conditional branching is managed using JQL-conditioned rules.

A minimal working implementation for addition is demonstrated by setting up a workflow with states like BACKLOG, TODO, DEV, and PROD, and using automation rules to simulate the Minsky operations. For instance, operations like decrementing a counter depend on the existence of linked issues, and branching is controlled by these conditions. The demonstration involves creating rules that trigger issue deletion or creation based on the counts of linked Bugs and Tasks, thereby executing the logical flow required by the machine. This process shows how Jira's automation language can encode the Minsky machine's principles.

Further complexity is introduced by showing that Jira's automation language can handle operations beyond simple addition, such as generating the Fibonacci sequence. This is achieved by utilizing the system’s ability to instantly change issue types, which the authors argue can be expressed through the combination of increment and decrement operations. By defining three states (TODO, QA, DEV) and three registers (Bug, Task, Story), the system can simulate the sequence generation. The transitions between these states are governed by checks on the linked issue counts, enabling the simulation of the recursive nature of the sequence. Although the system employs a chain-depth cap, the structure of the reduction remains valid, as the necessary control flow is supplied externally, affirming the Turing-completeness of Jira.

In conclusion, because Jira’s automation language allows for unbounded issue creation and rule execution, it can encode the necessary memory and control flow mechanisms of a Turing-complete model. Due to this capability, Jira is considered Turing-complete under standard computational conventions, implying that complex Jira automation sequences are functionally equivalent to programs.