Agent-Ready Check for Jira

Privacy Policy

Version 1.0 ยท Effective November 1, 2026

This policy explains what data Agent-Ready Check for Jira (the "App") uses, where it is kept, and how it is removed. The App is made by ARCH BADGER 500, LLC ("we", "us"), an Indiana company, and is sold through the Atlassian Marketplace.

1. The short version

  • The App runs entirely on Atlassian's cloud, on Atlassian Forge.
  • It checks Jira work items and scores how ready each one is to hand to an AI coding agent. The scoring is fixed rules in the App's code. The App does not send your work items to any AI model.
  • It saves a short readiness summary on each work item it scores (see section 3), and keeps its settings in Forge storage inside your Atlassian site.
  • It makes no calls to servers outside Atlassian. We run no servers of our own.
  • It does not store work item text, comments, attachments, names, or Atlassian account IDs.
  • We cannot read the data the App stores in your site.
  • We do not sell data, and we do not use it for advertising.

2. What the App reads

When a Jira admin installs the App, Atlassian asks them to approve these permissions:

  • read:jira-work: read work items, so the App can score them.
  • write:issue.property:jira: save the App's own ab500.ready.v1 summary on a work item (see section 3). This permission only lets an app save work item properties, which are small pieces of app data attached to a work item. It does not let the App edit fields, descriptions, labels, or status, or create, delete, comment on, or move work items. The App's code saves only its own ab500.ready.v1 property and never writes another app's data.
  • storage:app: the App's own storage, used for settings and, for each project, the time its settings last changed and a settings revision number.

To score a work item, the App reads its summary (title), description, type, project, status, labels, components, links to other work items and their status, the names and file types of attachments (not the files), and custom fields such as story points, size, risk level, and acceptance criteria. It reads a work item when it is created or changed, when someone opens it, when a workflow transition checks it (see section 5), when someone asks a Rovo tool about it (see section 6), and after a project's settings change, when it re-scores the project's work items in the background (see section 3).

The App asks for no permission to call servers outside Atlassian.

3. What the App stores

The App stores only these things:

  • Settings. For each project whose admin changes them: the readiness threshold, which checks are on, each check's weight and severity, the override label and other label names, the work item types to skip, size limits, word lists, and a map from component names to code repositories, plus any extra repository names. Admins type these in. A repository name may include the name of a GitHub account or organization, which can be a person's username. Settings hold no work item content.
  • Settings change time. For each project, the date and time its settings were last saved or reset. The App uses it to tell which summaries were made under older settings.
  • Work item summary (ab500.ready.v1). On each work item it scores, the App saves a small summary as a Jira work item property, so you can search it with JQL (for example ab500ReadyVerdict = "not_ready"). It holds only:
  • the score (0 to 100, or empty if the work item type is not checked) and the verdict (ready, not ready, or not checked)
  • the threshold that applied
  • the IDs of the checks that failed (such as AR-01), and how many of them are blockers
  • whether the override label was on the work item
  • the version of the rules, the project's settings revision number (it goes up by one each time the project's settings change), and when the work item was scored
  • the App's name and version, the summary format version, and when the summary was updated

It holds no text from the work item, no repository names, no costs, no secrets, and no names or Atlassian account IDs. It does not record who added an override label. Jira's own work item history shows that, as it does for any label. The summary is kept in your Jira site, not in Forge storage, and it is limited to 2 KB. The App rewrites it when the score result changes. After a project's settings change, the App marks that project's summaries "rules changed" and re-scores them under the new settings, even if the result comes out the same. It does this when someone opens the work item, when the work item changes, or in a background job that works through the project's work items a few at a time.

  • Re-score jobs. To run the background re-score, the App puts short jobs on Atlassian's Forge job queue. A job holds only a project ID, the settings change time, a page marker for Jira search, or a work item key. It holds no work item content. Forge keeps a job until it runs, and for at most 24 hours (up to 96 hours if Atlassian's platform has problems).

The App does not store work item descriptions, comments, attachments, or source code. Because it stores no Atlassian account IDs or other personal data from Jira, it has nothing to report to Atlassian's personal data reporting service.

4. Where the data is kept

Settings and the settings change time are kept in Forge storage on Atlassian's cloud, in your site's data residency location. Re-score jobs pass briefly through Atlassian's Forge job queue on Atlassian's cloud. Atlassian's Forge data residency documentation covers Forge's long-term storage and does not list this queue, which holds no work item content. The ab500.ready.v1 summary is kept on the work item in your Jira site. Atlassian hosts and protects both. Atlassian's own privacy policy and Forge data protection documentation apply to that hosting.

Nothing the App stores or reads leaves Atlassian, except as described under Rovo and AI tools in section 6, when your admin and your users choose to connect an outside AI tool.

5. The workflow validator

A Jira admin can add the App's validator, "Work item is agent-ready", to a workflow transition. When someone makes that transition, the App scores the work item, including any changes made on the transition screen. Depending on the admin's choice, it blocks the transition if the work item is not ready, or only if a blocker check fails. The message it shows lists the score, the threshold, and the names of up to three failed checks.

The validator saves nothing beyond the summary in section 3. It does not record who made the transition.

6. Who can see the data

  • People on your Jira site who can see a work item can see its score and failed checks in the App's panel. The panel and badge show only work items that person can see.
  • Project settings can be seen and changed by that project's admins and by Jira admins.
  • Work item summaries (ab500.ready.v1) can be read by anyone who can see that work item, including through JQL search and Jira's REST API, and by other apps installed on your site that can read work items, including other Arch Badger 500 apps. The summary is saved by the App itself, so it reflects the whole work item, even parts a particular viewer can't see. It contains no text from the work item, names, account IDs, or secrets.
  • Rovo and AI tools. The App offers a Rovo agent ("Agent-Ready Coach") and three read-only tools to Rovo, Atlassian's AI: one scores a single work item, one lists the failed checks so Rovo can suggest a better description, and one lists work items in a project that are not ready (at most 50, with each work item's key, title, score, and failed checks). The results can include short pieces of the work item's text that a check flagged, such as vague words, phrases like "as discussed", sensitive topics, and the keys of blocking work items. The tools run as the person using them, so they only return work items that person can see. They never change a work item. A site admin can also choose to let outside AI tools that support the Model Context Protocol (MCP) use these tools through Atlassian's MCP service. This is off unless an admin turns it on. If it is on, the results go to the AI tool the person connected, and that tool's own terms apply. The App itself still makes no calls outside Atlassian.
  • We cannot see it. The App sends nothing to us, and Forge does not give us access to the data it stores in your site.
  • App logs. The App's logs record work item keys, verdicts, whether a summary was saved, short error messages, and, for the validator and the background re-score, only reason codes, error types, and counts. They do not record work item text, people's names, account IDs, or secrets. Atlassian controls whether we can see these logs for your site.

7. How long data is kept and how it is removed

The App keeps its data while it is installed on your site. It has no fixed retention periods of its own. It updates work item summaries as described in section 3, but it never deletes one. Re-score jobs expire from Forge's queue as described in section 3.

When a project admin resets the project's settings, the App deletes them from Forge storage and records the time of the reset and raises the settings revision number.

When a Jira admin uninstalls the App, Atlassian's Forge platform deletes the App's settings and settings change times for your site, and the App can no longer read them. Atlassian's documentation says it keeps a deleted copy for 28 days after an uninstall, so we can ask Atlassian to restore it to a reinstalled App if you ask us within 21 days, and then destroys it under its own retention policy. A reinstall starts with the default settings.

The ab500.ready.v1 work item summaries are saved in Jira itself, not in Forge storage, so they remain on work items after an uninstall, and anyone who can see a work item can still read its summary through Jira's REST API. A Jira admin can remove them with Jira's REST API (DELETE /rest/api/3/issue/{issueKey}/properties/ab500.ready.v1).

Because we cannot access your site's data, uninstalling the App, and removing the work item summaries as above, is how you remove it.

8. When you contact us

If you email support@archbadger500.com, we receive your message and anything you attach. Our support mail is routed by Cloudflare and delivered to a Google mailbox. We use it only to answer you and fix problems. Please don't send secrets, passwords, or real customer data.

9. Our website

Our website, archbadger500.com, uses Cloudflare Web Analytics to count visits. This is separate from the App.

10. Security

The App relies on Atlassian's Forge platform for hosting, storage, encryption, and access control. If we learn of a security incident in the App that affects your data, we will tell affected customers, as set out in our Service Level Agreement.

To report a security issue, email support@archbadger500.com with SECURITY in the subject line.

11. Changes to this policy

If we change this policy, we will post the new version on this page with a new version number and effective date.

12. Contact

ARCH BADGER 500, LLC (Indiana, USA). Email support@archbadger500.com

This policy is governed by the laws of the State of Indiana, USA.