Recurrence Radar

Did your CAPA actually work? A Jira app that flags repeat deviations, catches CAPAs that failed, names who fixed it before, and drafts the investigation. Runs fully on Atlassian.

Comment

Inspiration

In pharma and medtech, every quality problem gets a ticket: a deviation. When the root cause looks fixed, a CAPA (corrective and preventive action) is raised, carried out and closed. Auditors then ask one hard question: did the CAPA actually work?

Most teams can't answer that quickly. The history sits in hundreds of old tickets, and nobody re-reads them when a new deviation comes in. So the same fault on the same machine comes back months later, and someone starts a fresh investigation from a blank page. Many of these teams already track deviations in Jira, so we wanted the answer to show up right where the work happens.

What it does

Recurrence Radar is a Jira app for quality teams. When a new deviation is logged, it checks the full history and shows, right on the issue:

  • Has this happened before? Similar past events, each with the reasons it matched (same equipment, same failure mode, same product, shared terms).
  • Did the last CAPA work? If a linked CAPA was closed and similar deviations happened after it, the CAPA is flagged as likely ineffective, with the repeat tickets on a timeline.
  • Who to ask and which SOP. The people who resolved similar events before, and the SOP most often involved.
  • An investigation draft. One click writes a first draft that cites the earlier tickets. The user reviews it and posts it as a comment.
  • A project overview. Open high-risk deviations, CAPAs that did not hold, tos, and an 18-month timeline.
  • A glance and a label. A "Recurrence check" lozenge on every issue and a recurrence-high label you can filter on.

To make it easy to try, the settings page has a Load demo QMS button. It creates a realistic demo project with 6 SOPs, 40 deviations and 8 CAPAs spread over 18 months.

How we built it

It is built on Atlassian Forge and runs fully on Atlassian: no outside services and no egress, so it qualifies for "Runs on Atlassian".

  1. A Jira trigger fires when an issue is created or updated, and puts the issue on a Forge queue.
  2. The queue consumer uses Forge LLM to pull out the equipment, product, faim the free text. If the LLM is turned off or the daily cap is reached, a
    1. The scoring logic is plain, unit-tested JavaScript. Each past event gets a similarity score:

$$\text{sim} = 0.35\,E + 0.30\,F + 0.15\,P + 0.15\,J(k_1,k_2) + 0.05\,R(\Delta t) + 0.05\,C$$

where \(E, F, P\) are 1 when equipment, failure mode or product match, \(J\) is the Jaccard overlap of keywords, \(R\) is a recency factor (full credit inside 90 days, fading to zero at 2 years), and \(C\) is a bonus for the same root cause. Events above 0.45

  1. A CAPA is likely ineffective when matched deviations are dated after its c by how often they resolved similar events.
  2. The UI is Custom UI with React and Vite: an issue panel, an issue glance, a project page and an admin page. It uses Atlassian design tokens, so it follows Jira's light and dark themes.
  3. A weekly scheduled trigger reports stored account IDs through Atlassian's personal data reporting API and erases data for closed accounts.

## Challenges we ran into

  • A consent loop. Our first version made some calls as the user. Under some conditions Jira kept asking for consent again right after the user accepted, and the settings page got stuck. We redesigned it so the app makes every call as itself, admin-only actions are e's module context, and posted comments name the person who posted them.
  • Analysis is async, the UI is not. The panel and glance can open before analysis is done, so they had to show a clear pending state and refresh on their own when the result lands.
  • Staying fully on Atlassian. No webtriggers in production, no external APIa rules fallback, so cost and data never leave the customer's site.
  • Making demo data feel real. A recurrence story only works if the history makes sense: CAPAs that closed, faults that came back, the same people fixing the same machines. We wrote the demo set so the patterns hold up when you click through them.

## Accomplishments that we're proud of

  • A real answer to a real audit question, inside Jira, in seconds.
  • Every match explains itself. Quality teams don't trust black boxes, so each result says why it matched.
  • Fully on Atlassian, with privacy handled: deleted issues are erased, and closery week.
  • Anyone can try it in two minutes with the built-in demo project.

## What we learned

  • Forge SQL, queues and Forge LLM together make a full analysis pipeline possible without running any servers.
  • Simple, explainable scoring beats a clever model when users have to defend thLM is most useful for reading messy free text and writing drafts, not for makingthe decision.
  • Permissions and consent shape the design as much as the features do.

## What's next for Recurrence Radar

  • Publishing on the Atlassian Marketplace.
  • Custom field mapping for teams that use their own deviation and CAPA fields.
  • Trend alerts when a machine or product starts drifting before it becomes a de
  • Support for Jira Service Management and Confluence SOP pages.

Built With

Share this project:

Updates

Submission history