Jira is Turing-Complete

# Jira is Turing-Complete Source: [https://seriot.ch/computation/jira.html](https://seriot.ch/computation/jira.html) ### Nicolas Seriot #### [Computation](https://seriot.ch/computation/index.html)\> Jira is Turing\-Complete *Building a Minsky Machine in Atlassian Automation* *22nd May 2026* Engineering folklore[holds](https://news.ycombinator.com/item?id=17689446)that[Jira](https://www.atlassian.com/software/jira)\(Atlassian's project\-tracking tool\) is[Turing\-complete](https://esolangs.org/wiki/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](https://esolangs.org/wiki/Minsky_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* - *decrement register R, if R == 0 goto some state, else goto some other state* 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](https://en.wikipedia.org/wiki/Marvin_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 MachineJiraRegister ACount of linked issues of type**Bug**Register BCount of linked issues of type**Task**Program CounterStatus of a single**Epic**issueDispatch TableJira Automation rules, one per instruction stateClockAutomation\-triggered transitions, or external re\-triggering past chain capsThe Epic's status encodes the current instruction\.[Automation rules](https://support.atlassian.com/cloud-automation/docs/create-and-edit-jira-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](https://support.atlassian.com/cloud-automation/docs/jira-automation-conditions/)\. ### 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\. [](https://seriot.ch/resources/jira_tc/addition_rules.png) **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 Two States The reduction above suffices to prove Turing\-completeness\. Jira's automation language makes non\-trivial programs tractable by using Convert Issue Type\. Jira's*Convert Issue Type*action changes an issue's type instantly: Bug → Story, Story → Task, and so on\. A single Convert merges DEC\-on\-one\-register with INC\-on\-another into one atomic operation\. It doesn't extend Jira's computational power \(a Convert is expressible as DEC \+ INC\) but it shrinks the dispatch table dramatically for any move\-loop\. Fibonacci as`\(A, B\) → \(B, A\+B\)`collapses to two states with three registers \(A=Bug, B=Task, C=Story\), using`TODO`and`QA`\(add it to the workflow\) as the two instruction states: ``` TODO: if any linked Bug exists: Convert Bug → Story INC Task transition to TODO else: transition to QA QA: if any linked Story exists: Convert Story → Bug transition to QA 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\.