TraceGuard

Audit-ready traceability for regulated software teams: a Rovo agent and Jira page that give a GO / NO-GO release verdict and publish the audit report to Confluence.

Comment

Inspiration

What it does

How we built it

Challenges we ran into

Accomplishments that we're proud of

Inspiration

In regulated industries (medical devices, automotive, pharma) a team cannot ship a release until it proves that every requirement was tested and every safety risk is controlled. Standards such as IEC 62304, ISO 14971 and ISO 26262 call this traceability. In practice it lives in a spreadsheet that someone rebuilds by hand before each release or audit. It goes out of date the moment a test fails or a requirement changes, and gaps are often found late, sometimes by the auditor. The links needed to answer the question already exist in Jira, so we wanted Jira to answer it.

What it does

TraceGuard turns the issues and links a team already keeps in Jira into a live traceability matrix and a clear release verdict.

  • Rovo agent. Ask "Is IPC v2.1 ready to release?" and the TraceGuard agent answers GO or NO-GO, lists every gap with its Jira key, and gives one concrete next step for each. High-severity risks come first.
  • Jira project page. A TraceGuard tab shows a red or green verdict, six key numbers (coverage, requirements verified, tests passed and failed, risks with gaps, high risks open), the requirement matrix and the risk control table, with a release picker and a Refresh button. Every key links back to its issue.
  • Audit report in one click. "Publish audit report" (from the page or from chat) writes a dated Confluence page with the verdict, the matrix and the risk table.
  • MCP tools for any AI client. The same checks (get-traceability, check-release-readiness, publish-audit-report) are exposed through the Rovo MCP server with the rovo:mcp module, so Rovo Studio agents or external MCP clients such as Claude or Cursor can ask TraceGuard for a release verdict, with the user's own permissions (a site admin turns on "Expose tools to MCP-compatible apps").
  • Six kinds of gap: requirement with no test, failed test, test not run, requirement changed after it was tested, risk with no control, and risk controlled only by unverified requirements.
  • Demo in one sentence: "Load the TraceGuard demo project" creates an insulin-pump controller project with 8 requirements, 8 tests and 5 risks, including deliberate gaps.

How we built it

  • Atlassian Forge, running on Atlassian: no external servers, no data leaves the platform.
  • Rovo agent (rovo:agent) with four actions: get-traceability, check-release-readiness, publish-audit-report and load-demo-project. The prompt tells the agent to use only facts the actions return.
  • Jira project page (jira:projectPage) built with Forge UI Kit (@forge/react) and a resolver (@forge/resolver).
  • Jira REST API (JQL search, issue links, versions, bulk create) and Confluence REST API (spaces, pages with status macros), all called with asUser() so permissions are respected.
  • One small, pure trace engine shared by the agent, the page and the report, with an offline test, so the three never disagree.
  • No custom fields and no setup: labels (tg-req, tg-test, tg-risk, tg-pass, tg-fail, tg-changed, tg-sev-*) and ordinary issue links that every Jira site already has.

Challenges we ran into

  • Keeping the release rule simple enough to explain to an auditor but strict enough to be useful: GO only when every requirement is verified by a passing, up-to-date test and no high-severity risk is left without a verified control.
  • Detecting requirements that changed after testing without custom fields.
  • Making one engine serve a chat agent, a project page and a Confluence document.

Accomplishments that we're proud of

  • The same answer everywhere: agent, Jira page and Confluence report come from one engine.
  • Zero setup on a real Jira site: labels and links only.
  • The full story works end to end: NO-GO with reasons, fix the gaps in Jira, Refresh, GO.

What we learned

How Rovo agents decide when to call actions, how to design action outputs so the agent can explain them without inventing facts, and how Forge UI Kit pages and resolvers fit together with the product APIs.

What's next for TraceGuard

  • An automation rule that adds tg-changed when a verified requirement is edited.
  • Verdict history per release and export formats auditors ask for.
  • Results from test-management apps in addition to labels.
  • Publishing on the Atlassian Marketplace.

TraceGuard is decision support; the quality / regulatory team owns the release decision. The demo data is synthetic.

What we learned

What's next for TraceGuard

Built With

Share this project:

Updates

Submission history