Passport Ready

EU battery passports become mandatory on 18 Feb 2027. Passport Ready turns Jira into the readiness tracker: 37 legal data points, evidence-checked AI proposals, human verification.

Comment

Inspiration

From 18 February 2027, every electric vehicle battery, every light-means-of-transport battery (e-bikes, e-scooters) and every industrial battery above 2 kWh placed on the EU market needs a battery passport: an electronic record reachable through a QR code (Regulation (EU) 2023/1542, Article 77). Annex XIII lists what it must contain, split into three access levels: the public, people with a legitimate interest (repairers, recyclers, second-life operators), and the authorities.

Manufacturers already track their products in Jira, but the passport data is scattered across datasheets, test reports and supplier emails. Nobody can answer the simple question: how ready are we, product by product, and what is still missing?

What it does

Passport Ready is a Forge app for Jira. Each work item is a battery model.

  • Issue panel:
    • pick the category (EV, LMT, industrial with capacity);
    • see which Annex XIII data points apply (36 or 37);
    • see the verified count and the days left before the deadline;
    • fill or edit values;
    • see the split by access level;
    • export the verified data as JSON grouped by access level.
  • Scope rules from the law: an industrial battery of 2 kWh or less is flagged "not required"; the capacity threshold for exhaustion applies only to EV batteries.
  • Portfolio page per project: every battery, least ready first, with the countdown.
  • One click "Create data request tasks": one Jira sub-task per access level, listing the missing items with their Annex XIII references.
  • Rovo agent "Passport Ready" with 7 actions:
    • read the datasheet pasted in a work item;
    • check readiness;
    • list portfolio gaps;
    • propose values with evidence;
    • draft data requests;
    • create tasks;
    • export.
  • The same actions are exposed as an MCP server (rovo:mcp), so tools such as Claude Code can use them, with the user's own Jira permissions.

The part we are proudest of: the code checks the AI

In our first test, the Rovo model could not see the work item description, so it invented values and the evidence lines to go with them. For example, it gave the manufacturer as "Volta Energy Solutions" (the datasheet says "Volta Energy S.r.l."), "2,500 cycles" (it says 3,000), and "copper powder or dry sand" as extinguishing agent (it says water and class D powder).

We added a deterministic guard: a proposal is stored only if the quoted evidence line really exists in the work item description or comments and contains the proposed value. Every invented proposal was rejected and nothing was saved. With a read-source-text action, the agent now proposes values copied verbatim (21 of 21 correct on our test datasheet).

Even then, an agent value is only proposed. It does not count until a person verifies it in the "To review" tab, next to its source line.

How we built it

  • Forge (Node 24 runtime) with UI Kit:
    • modules jira:issuePanel, jira:projectPage, rovo:agent, 7 action modules and rovo:mcp;
    • Forge CLI 14.2.
  • Data stays in Jira, as an issue entity property on the work item, so it follows Jira permissions and backups. There is no external egress and no external AI API, so the app is eligible for Runs on Atlassian.
  • Security: the app writes with app credentials. Every resolver and agent action therefore first asks Jira, as the calling user (asUser, mypermissions), whether that user may browse, edit or create in that work item. The user identity comes from the Forge context, never from agent inputs.
  • Rules engine: a pure JavaScript module built from the text of the Regulation (Article 77, Annex VI Part A, Annex XIII), with 13 unit tests:
    • scope thresholds;
    • per-category data points;
    • agent values stay "proposed";
    • export contains only verified values;
    • the evidence guard, including the real hallucination case.

Challenges

  • Rovo agents are not available on free developer sites, so we tested on a Forge demo site.
  • UI Kit controlled text fields dropped characters while typing; we moved to Form/useForm.
  • The bulk permission-check API needs Jira admin rights; we switched to the user-scoped mypermissions endpoint.
  • Agents hallucinating evidence, solved by the guard and the read action above.

What's next

  • ESPR delegated acts for other product groups (textiles, steel, electronics), with the same engine and new rule packs.
  • An export mapped to the EU Digital Product Passport registry data model once it is final.
  • A Confluence page per passport for the public part.

Built with

Atlassian Forge, UI Kit, Rovo agents, rovo:mcp, Jira REST API, JavaScript, Node.js

Demo video

https://youtu.be/WcifbUO9s1g

Built with AI assistance (Claude Code), directed and reviewed by the author. The battery data and the company Volta Energy shown in the demo are fictional.

Built With

Share this project:

Updates

Submission history