Jira Is Turing-Complete

Source: Hacker News

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'

In plain English:

• increment register R, then goto some state S
• decrement register R; if R == 0 goto zero‑state S, else goto non‑zero‑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.

Mapping to Jira

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

Below is a minimal working implementation using one Epic, linked issues, and one automation rule per instruction state (Space Settings → Automation).

1. Create Workflow

Create a Jira workflow with statuses: BACKLOG, TODO, DEV, and PROD. Any state can transition to any other. Create an Epic in status BACKLOG.

2. Create Rule for TODO

Logic: 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

Logic: INC B; goto TODO.

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

Both rules have “Allow rule to trigger other rules” enabled.

4. Initialise 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. The sequence of transitions is:

(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 ends in PROD with 0 Bugs and 5 Tasks linked—exactly the sum 2 + 3 = 5.

Fibonacci in Three States

The reduction above suffices to prove Turing‑completeness. Jira’s automation language also offers a convenient “Convert Issue Type” action (e.g., Bug → Story, Story → Task). This CONVERT operation can be expressed as DEC + INC; it does not extend computational power but shrinks the dispatch table dramatically.

A Fibonacci generator using three registers (A = Bug, B = Task, C = Story) and three instruction states (TODO, QA, DEV) can be written as:

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

Starting with A = 1, B = 1, C = 0, the Task count (B) yields the sequence 1, 1, 2, 3, 5, 8, 13, …

Unlike the addition machine, the Fibonacci machine has no halt state; it runs until Jira Cloud’s chain‑depth cap (10) triggers, after which the operator re‑triggers the Epic to continue. A single status edit restarts the cascade. Jira Data Center exposes the same limits via 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. Physical computers are finite, so Jira Cloud’s finite quotas do not refute the construction. Under the standard convention that “unbounded” means “no theoretical limit,” Jira is Turing‑complete.

So, if complex Jira automations feel like programs, it is because they literally are.