--- title: "Simplifying 62304 and AI Compliance with Jira and Polarion" type: webinar-transcript publisher: Ketryx source: "https://fast.wistia.net/embed/iframe/28klji5gje" content: auto-caption transcript, proper-noun corrected --- # Simplifying 62304 and AI Compliance with Jira and Polarion *Ketryx webinar — transcript of the recorded session.* [▶ Watch the recording](https://fast.wistia.net/embed/iframe/28klji5gje) --- So good morning, everyone, and welcome to our webinar. We'll get started in just a couple of minutes. so perhaps while we wait, we can start with a few logistical announcements. So first of all, we will record this webinar, and you'll receive it in an email afterwards along with the slides. Then go ahead and put questions in the q and a at any time. Our colleagues, Isken and William, are on the line, and they will be surfacing your questions, from the chat to us throughout the presentation. We'll do our best to answer as many of the questions as possible live, but we also have a team of subject matter experts, staffed staffing our chat at the moment, and they might answer your questions in the chat. If you have to leave at any point, you'll see a survey that we'd really appreciate you completing to give us feedback on this webinar. And then finally, we are also placing the link to register your interest in our next webinar on Thursday, June twenty six in the chat. The topic will be navigating, the FDA PCCPs for AI driven medical devices with Beacon Biosignals. This will be a really interesting webinar, so feel free to register at any time. So, let's look at the poll results so far. It looks like, we have about twenty five percent, of people using Polerin, but they would like to use it more. And then seventy five percent chose other. So so it's a lot of just they're trying to learn about Polarion. Don't know if you're gonna use Polarion. And then, yeah, I think this other one that's that stands out is, like, teams today are oftentimes using Polarion for require like, requirements, risk, and system level testing. But when it comes to software, which is what we're gonna talk about today, a lot of that work is being done across a number of different tools, whether those are ticketing systems like Jira, which will cover, Azure DevOps, or even some additional QA tools like TestRail or Tricentis. So that that all all makes all makes sense. Okay. Shall we, get going? And, Gabriel, do you wanna kick us off with the introduction to Ketryx? Yeah. Absolutely. Thanks, Yolani. So hey, everyone. We'll do introductions to your host in a moment here. But I wanna give a quick introduction to kinda center us around what Ketryx, the the platform and the company focuses on, particularly in the context of working with solutions like Polarion, which are application life cycle management tools. What we found over time, within the industry, tooling specifically, is that tools like Polarion, like Jama, have over time made connections out to additional SDLC tools. The the purpose the original purpose of a tool like Polarion is to manage that complete life cycle in Polarion. But there's a lot of aspects of the software development life cycle that need to be managed in additional tools. Those are tools like Jira, which are commonly used for organizing software development work, executing QA. Those are tools like your code hosting repository, like GitHub, Azure repos, Bitbucket, where a lot of the testing information and and documentation, frankly, lives and needs to be related to documentation and activities that take place in Polarian. So these links have been over time created to external systems, but they're they're mainly focused on synchronizing information and not necessarily enabling you to orchestrate a life cycle across a set of tools. And so that's where Ketryx comes in. When Ketryx works alongside Polarion, we enable you to get all of the utility you are using Polarion today for, but allow you to manage aspects of the life cycle across other core tools in your tool chain, such as Jira, GitHub, and other SDLC, focused products. I think this will make a lot more sense as we get into a demonstration and and talk about some of the core problems that we see for teams using Clarian in Jira. But I hope this gives an initial introduction into to where we fit in the space. I'll hand it to you, Yolani, for an intro. Thank you, Gabriel. So as I said before, my name is Yolani Della Porta. I'm a director of client operations here at Kitrix, and so I work very closely with our enterprise clients to lead implementations. I have more than ten years experience leading technology implementations with large enterprises and health systems. One of the previous companies that I worked for is called Adriatic Health, and they used AI for gastroenterology. I've also worked at a a company called Northwell Health where I, developed AI systems for, population health and deployed that across health systems. Gabriel, would you like to say a little bit more about yourself? Yeah. Absolutely. Hey, everyone. Gabriel Pasquale. I run the solutions engineering organization here at Ketryx. So I help folks evaluate and, support some of the initial steps of the implementation of the platform. Prior to Ketryx, I started my career in cybersecurity. I worked at the MITRE Corporation as an embedded system security engineer and helped manage their cyber innovation portfolio, which crosscut into health care. So a lot of the tools that are used within MedTech, whether it's, the CVE database and CVSS scoring, whether it's the ATT and CK framework, all of these things, are happening and were developed over at MITRE. Following MITRE, I spent time at Amgen where I was applying AI on the manufacturing side of the business, and that's where I ran into a lot of the challenges of developing validated software and AI systems. I ended up meeting the the founder and CEO of Ketryx and and joined a few years ago to help folks, evaluate and implement Ketryx. So so happy to be here, and and I'm excited to show a demonstration and and kind of further this discussion. So, Yolani, back to you to to talk about the agenda. Thank you, Gabriel. So let's just briefly look at the agenda for today. As you know, Jira and Valerian are among the most commonly used software development tools in the world, and so it's familiar to many, developers. And so today, we'll walk through the benefits of modern development tooling like Jira and Pilarion. We'll discuss why this webinar matters in the context of industry trends, and we'll review some of the common use cases for Valerian with other software development life cycle tools. Then we'll look at the key requirements for sixty three zero four and how to apply sixty three zero four to tier on Valerian. And then Gabriel will lead us through a review of a life Polarion instance that's integrated with Getrix and discuss the key benefits of the total product life cycle approach. And then finally, we'll end with some questions and answers. But as I said earlier, we love questions, so please feel free to post questions throughout the web webinar. So let's get started and, talk a little bit more about why we are here. The main reason teams use developer tools like Jira and Polerin is because software is becoming more and more complex over time. And so this is a graph, from a McKinsey study about medical device software development. It shows that the design complexity of building medical device software is growing really rapidly at about thirty two percent a year. And that's a result of AI and machine learning, the mobile revolution, increased functionality, connectivity to the Internet, and many other things. What's interesting is that at the same time, the productivity of software development teams and med tech has remained quite flat at only about two percent. So many companies, try to hire just more and more people to address this problem. But as many of you know who have developed a lot of software, hiring more people doesn't always help you go faster. It can make things even more complicated. So teams turn to tools like Jira to help them increase their productivity. But the challenge is, Jira wasn't built for regulated environments. It lacks native support for traceability, risk management, and validation workflows. And that's where tools like Valerian come in to, provide a structure for requirements management and system level validation aligned with standards like IEC sixty three zero four. But the challenge is that it's very difficult for Jira and Polarian to work together. So what we've seen is that teams often get stuck in a very manual process and duplicating work that just increases the complexity and increasing audit risk. So next, we'll talk a little bit more about the evolution of the developer tooling over time to understand how people are trying to resolve this complexity. So software development as a practice really started in the fifties and sixties, mostly in the government for defense projects. And as it grew, it was mostly used in high reliability scenarios like this because the these were the organizations that had the funding for the software development. So in the early nineties, as the focus was mostly on aerospace and defense, it was mostly about a hardware product life cycle management before people started using these tools for to manage software projects. And what defines a trend of the tools at this time was that many of them were used to be a single source of juice in one single place to manage all of the features related to the product and the software life cycle. But that became very challenging over time because software became much larger and more complex. And so in two thousand to two thousand and tens, as the agile started to explode, software development expanded beyond those regulated applications, and there were a lot more consumer applications because of cloud, web apps, mobile apps, and the Internet. And so with those consumer applications of software, companies started getting rapid feedback from the market to improve the product. And so, Gabriel, if you click again, we can see, that we started to see tools that manage these agile workflows that removed a lot of the controls that we saw in the regulated development. And then from the mid twenty tens, we started to see a surge in data driven applications and more development tools aimed at solving the issues that pertain to data driven development and focusing on massive data sets, especially AI and machine learning development growth. And so over time, we have this growing developer tooling ecosystem to manage the complexity of AI and machine learning, web applications, mobile applications, and larger deployments. But these, tools largely ignore high risk applications because they are slower. And this is actually ironic because those high risk applications is where the software development initially began. Yolani, one thing I'm I'm just realizing as we go through this this evolution here is we almost need to add an additional box, for all of the AI tools that are coming out. Because one of the other trends that we're seeing and what we'll discuss when we go to the demo environment is that all of these enterprise AI solutions are coming out, whether that's Gemini, CheckTBT, tools from Anthropic, both the models and the the interfaces. And what is occurring is teams wanting to apply those technologies across all of the tools that we see in this evolution. And so there there's simultaneously what we'll talk about today is a way to connect these tools from a perspective of a life cycle, but also how can you better leverage the AI tools that are now in the market in the last two years holistically across the life cycle. And I'll I'll take an a mental note to make an update for our next time we go through this. That's a great note. Thank you, Gabriel, for adding that. And and in the next slide, we'll we'll touch a little bit on the AI use cases as well. So next, we'll take a look at what software teams are really trying to achieve when working with Valerian alongside other tools in their software development life cycle. So first, teams want to enable agile workflows across disconnected systems like Valerian, Jira, and Git. And in the regulated environment, it's critical to develop and verify software in parallel, like when you wanna do a quick patch release, but that's hard to do when each team is using a different tool. And so teams are looking for ways to keep the velocity high without sacrificing, traceability and compliance. For the second one, with the rising importance of cybersecurity and SPA management, organizations need to connect, security findings directly to the development and the documentation process. So what that means is ensuring vulnerabilities are traceable all the way through to cyber and safety risks, ideally without any manual overheads. And then finally, many organizations operate multiple Blur and Instance and struggled with siloed information. So these multiple instances can come from acquisitions or different teams using different instances. And this there's a growing need to analyze changes across these systems, trace requirements end to end, and then generate unified documentation that doesn't require constant reconciliation. So in today's webinar, we'll mostly focus on the first use case, enabling agile workflows across Polaron, GR, and Git, and we'll walk through what teams are trying to achieve and how they're doing it today, and Gabriel will also do a demonstration. Now, of course, as Gabriel, correctly, identified in the previous slide, across all of these use cases, we also have a AI agent component. And so in the first use case, Ketryx agents can suggest traceability between Jira user stories, test cases, and system requirements in Pilarion so you're not mapping things manually. For the second one, one way Ketryx agents can be used is to automatically generate safety and cyber risks in Pilarion based on vulnerabilities found in your SBOM. So you're not manually copying data between tools or missing critical, links. And then finally, we can also use Ketryx agents, to help you identify conflicting or redundant requirements across different Polarion instances, making it easier to manage complexity and ensure consistency between these different systems. So next, we'll go to our second poll, and we'd love to learn more about what your biggest challenges are in achieving some of these use cases with Polarion and Jira. And so we'll we'll give a couple of minutes for people to respond, and then we'll review some of the results with you. Definitely seeing some people go for difficulty to see traceability across the entire system. I can echo that's that's something we see a lot of people, struggle with, and a lot of, like, duplication, in systems to try and resolve that. Okay. So I think, let's go through the results. So the first one is developing and testing software versions in parallel. About twenty two percent of you guys find that hard. Then the difficulty to see traceability across the entire system, that's the majority, about seventy eight percent. Then manual copying pasting work, in Jira to generate documentation and, capture the entire development process, that's definitely one we see a lot as well. Sixty seven percent. And then, the lack of automated testing and difficulty managing SIP and SBOM components, and then a few others. So this brings us to why is this webinar important. And the goal of this webinar is to show you how to simplify the the traceability, the test management, and the documentation across these different systems without duplication so you can bring your products to your patients quickly and safely. So many of you have already introduced the agile software practices, through tools like Jira or ADO in your companies. But what we've seen is integrating these agile practices with design control processes in systems like Valera is where, it still remains a challenge for clients. So being agile across the entire project life cycle is really hard, and that's because incremental development depends on synchronization between systems like Polarion and Jira, something that most teams struggle to achieve. And that's the gap that we're trying to address in today's, webinar. So next, Gabriel will talk us through, sixty three zero four and the software development life cycle before jumping into a demonstration. Yeah. Awesome. Thanks, Yolani. Yeah. I think it's good to center the conversation on different stages of six two three zero four. We have this this chart here that really kinda goes through each of the the phases here from software development planning, which often is taking place in a tool like Clarion. Some teams have have started to do more of that in in Jira and ADO. We move through requirements analysis. There was a question, in the the q and a on whether or not the the topics that we're covering today also apply to a requirements management tool like Jama. And and, yes, the same is true. We do have support for for Jama. And a lot of the same use cases and challenges that we're talking about, we also see, with teams, on that front. So so I definitely think you can kind of apply the the thinking that we present today to other requirements management tools. But moving down from from software requirements analysis, we get into kind of architectural design. We see tools like draw dot draw dot io, enterprise architect, down to our software detailed design, which oftentimes, we're missing one logo there for software detailed design, which is is Word. We see a lot of folks, managing that software detailed design documentation in, in documents. And then moving down kinda into the different layers of testing, whether that's unit testing and and automation that lives in a CICD management platform like Jenkins, or an integrated platform like GitLab pipelines or GitHub actions. And then we move back up to the kind of software system testing and software release levels, where once again, we're we're working in tools that are closer to an ALM like Polarion. Now ultimately, I think the the important aspect to to identify here is that these tools are being used across different parts of of the v model. And there's a pretty clear split between where activities in Polarian happen and where activities happen in Jira. And ultimately, as we see on the right here, this is how documentation is often done for teams working in Polarion. The entire v model is represented in Polarion, although aspects of the documentation, originate from other tools. Most commonly, those tools are Jira, Azure DevOps, and the code repository. And it's oftentimes this bottom of the v from the specification or or maybe even starting at software requirements down that originates from these tools and then is manually traced or or synchronized up into Polarion so that you can have that complete end to end trace as well as if you're using, this tool for for document generation, generating those final deliverables. And so when we think about this this challenge at at Ketryx, we wanna solve that through two things. The first is that real time synchronization of data from sub from systems that support the bottom of the bee up to Polarion. And the second is synchronizing the idea of of versions, variance, and the ideas of approvals and process. We'll go over that more as we get into the the the demo environment, but this is a core aspect of Ketryx that enables you to manage the life cycle of your of your product across both of these tools rather than simply synchronizing data into Polarion and managing the entire life cycle directly in Polarion. So with that, we'll go into the demonstration environment. We'll start with an overall kind of introduction to to Ketryx. We'll dig into Jira and, as well as as Polarion. So what you'll see here when we first get into the Ketryx platform is a set of projects that we're managing. The projects are essentially a way to create a layer of abstraction across the set of tools in your organization. You'll see here that we have one project that's connected to Jira, as well as to GitHub. We also have another project here that's connected to Polarion. So a Caprix project can connect to any number of systems and then, consume objects from those systems. What Caprix then enables you to do is generate evidence, So documents that may include evidence that crosses those systems. That's the core core use case. The second is, and related to that, the ability to build traceability across those systems. And then finally, the ability to leverage AI that require, you know, use cases within applying AI in the product development that require access to content and traceability that cut across systems. So we'll start by going into the subsystem level and talk a little bit about Jira, and then we'll move up into the the system level where a lot of the system level requirements, risks, and testing is taking place in Polarion. I will highlight, you know, just because there was the question about other tools like Jama, and Azure DevOps, that the same concepts apply as we talk about a different ticketing system like ADO or a different requirements management system like Jama. Going into this particular Jira project, Jira Ketryx project, we'll be met with this all items screen. And what this is showing us is all of the work items that live over in Jira and are being actioned by teams that are familiar and prefer to use Jira. You'll see that the work items that live over in Jira include work item types that match to a requirement, a software item specification, so part of that that detailed design, test cases, and even some risk items. Whether or not you choose to manage these parts of the life cycle in Jira is up to you. This is just a sample environment to show you that you are capable of running the the full life cycle in Jira. But oftentimes, teams will have aspects or or types of these items that live up in Polarion. So for this example, we'll assume that we're managing software level requirements in Jira that trace up to system level requirements in Polarion. So if I open up one of these requirements, and let's choose, IDS thirteen, which is that Jira work item. If I open up this particular requirement, it'll bring me directly into Jira. And so what we're seeing is a very familiar interface with two, I guess, key changes, to point out. The first is this local traceability widget. This local traceability widget is inserted by Ketryx and gives you the user in Jira a sense of the local traceability of the particular item. So as you can see, this software requirement traces up to a system level requirement. The software requirement also traces down to some software specifications that live down in the source code in the code repository as well as some other aspects of, of our software design that we're documenting using work items in Jira. Finally, we'll also see that we're tracing some tests. In this case, we're executing tests in Jira. We might use X-ray test management, for example, for managing our test case, or we could even use an external QA tool like TestRail. But ultimately, this view gives us an understanding of how everything relates, what no matter what system the particular item comes from. The second component, and and this applies to, you know, all systems that we integrate into, is the ability to manage approvals in the connected system. So here, we can see an approvals widget that allows us to execute peer reviews and approvals on the software requirement directly in Jira. Now you may end up doing a document level review of all of your requirements, but what we find for software teams that wanna make incremental changes to their software and lower the scope or the size of releases in order to accelerate the release cycle time, that having this fine grained control and and level of approval allows you to make smaller scopes changes and therefore reduce the amount of time, between releases and get more towards that agile delivery method. On the right, you could see a number of fields. We have a default set of fields that are configured into every system, but this is configurable. Now if we go back up into the Ketryx side, we'll see an important component of both supporting auditability of using these systems as well as support some of the change management concepts we'll introduce later. And that's the ability to track complete history and audit trail changes that happen to an item no matter what system it comes from. So if you choose to use Ketryx as your your system of record or whether you export documentation from Ketryx, we have the ability to correlate the records that are exported in that document directly to a Ketryx record that is inter that you can interact with and understand more contextual clues that might not be exported in that original evidence document. In addition, this enables us to manage versioning across tools, and that comes back to this core challenge that teams have in enabling, software teams to manage the life cycle of the product across tools rather than just synchronizing information up into a system like Valerian. Let me just take a look at the some of the questions we have coming in here. Foundry. I will come back to this question around the methodology re related to agile, the PI product increment. Let's see. I might just need a a bit of a clarification around PI, whether that's product increment Program increment. On the QA. Do you see that question? So when we're following an agile you know, essentially, when we're following an agile method, and and driving product increments, understanding doneness. So I think, you know, this concept is can be a challenge if you aren't pushing most of that kind of software development life cycle closer into the the developer tools. So we can get into a little bit more detail on on how to enable, enable that agile methodology, but might be a little bit a little bit, out of scope for the demonstration. But I will say that a a big portion of that is allowing teams to execute as much of the life cycle in, SDLC tool like Jira and then allow teams to incrementally update documentation that lives in the system above, which is Polarium. So you're executing an agile sprint. And then at the end of that that product increment, leveraging tools like the Kedrix agent or assistant to automatically update by either creating new requirements, editing existing requirements based upon the stories that have been executed for that sprint. Really good question that I'd be happy to get into more on a on another call. So we've covered a little bit about the particular kind of audit, piece on a particular item and how that enables change management. Now if we move into the traceability view, we now are getting a sense of the traceability of a particular software subsystem. And, again, in this particular model, we're developing the software subsystem entirely in Jira. But this software subsystem is part of a product, a broader product, that's documented up in Polarion. So all of the system level requirements live in another tool. So what we'll do next is we'll go into that top level project and we'll take a look at the traceability view for someone who's managing the system level perspective on the product. And what we'll see here is a set of user needs, system requirements that come from Polarion. So each of these items within the trace matrix are being pulled from a Polarian instance where the system requirements are managed. And then as we get down to the subsystem level, which includes that software subsystem, we'll find that software requirement that's being managed in Jira. So if I filter down and look for IDS thirteen, we'll now see how this particular software requirement relates upstream to a Polarion system requirement and downstream to other software specification items that may live across Jira and Git. Now again, you know, to to the point of the question that was just asked, you may not manage requirements down in Jira. Maybe all of your requirements will live up in Polarion, but the traceability down to the software stories and tasks can still be represented in this particular trace view and enable you to execute that agile sprint, life cycle while still having traceability back up to the requirements that need to change or up to additional requirements that need to be added based upon the acceptance criteria that you've developed for a story. The final thing I'll point out here because I did mention it is this ability to trace down into the source code. So what we're finding with teams is when it comes to requirements or specifications relevant to software, finding ways to integrate more of that documentation in the source code allows teams to take to, a, take advantage of the Git based versioning and, b, do a truer documentation about what was actually implemented. I think a big challenge for teams today as they get through the documentation life cycle, they have a set of of SDDs, And those STDs are a bit too much of an abstraction of what was was implemented because they're often documented at the end. When we look at a particular item, for example, the sensor reading warning specification, we'll see oh, excuse me. I'll find a better example here. I will pull so I will pull that up in a moment. But what you'll see here is one of these particular items that lives over in the source code repository. And the idea is that as your developers are working, you can either document directly within the source code as a source code comment, use a markdown file for doing that documentation, or if there's a particular way that you want to extract documentation from your source code. Whether that's, doing class and activity diagrams, doing sequence diagrams, there's work that we can do together to automatically generate some of those artifacts that will then show up in in downstream documentation. But this is where we're seeing a lot of, progress from teams moving away from leveraging a word document for doing an STD and moving more towards automatically generating that STD from the source code. The same is true for testing artifacts. So for teams that are that are managing unit testing through automated frameworks like like Cucumber, JUnit, Pytest, one of the the core challenges we see among dev test or in sprint testing and verification testing is making sure there's visibility between both of those teams and getting one cohesive view where you can see all of the in sprint testing that's been done as well as the verification testing that will be executed during the V and V cycle. And one of the biggest challenges is around getting visibility into that, information. And that relates to a question that was was posed, over in the q and a, which is around does all of this traceability and AI help in terms of regression analysis? Understanding what test to run based on code changes going forward. And what we're describing here around getting greater visibility into the in sprint testing and unit testing as well as to the higher level verification and validation that might be done in Jira or Polarion is a core capability for you to get visibility for something like a regression analysis. And Ketryx and these views can enable you to to understand, what changes are going into the next the next version, and, therefore, what particular test cases need to be reexecuted. Alright. So we've talked a lot about Jira. We've talked a lot about integration into the the source code system. And now it's a question of how we can go back up to the system level where system teams are developing requirements, risk teams are documenting and executing risk analysis, and so on. And so here we have this this PADO, dash five one nine, which is a system requirement. Going into that system requirement in Ketryx, you'll see a a few different things. First, you'll see a familiar screen, for Polarion, which includes the ability to move statuses for the particular requirement and have those synchronized over to Ketryx. So everything we spoke to around the ability to to coordinate, a review and approval process, but a review and approval process that can trace across systems. So if you want a particular, change to a top level system requirement to cascade down and therefore require reverification of of children items, that's something that Ketryx can can enforce, from a process perspective. And I think that's easiest to see when we look at the traceability widget that's inserted into, Polarian as well as a panel. So we're looking at a particular system requirement in Polarion. We can see that this system requirement traces down to two software requirements that are being maintained in Jira as well as to a test that that lives in Polarion. Now if we did want to configure configure a control to help us work through change impact analysis, we can require reverification of downstream items when an upstream item changes. In many ways, this is, I guess, a a a more powerful powerful version of of suspect links, which enables teams, no matter where they're working, to understand when an upstream change potentially could impact their work. Now that we've covered the the traceability within Polarion, I think it's helpful to move back and and talk a little bit about how we can leverage some of the assistant and AI to accelerate our workflows. And then finally, we'll wrap up with with generating some some documentation which is that that final step when we're working within these tools. So what we'll do is we'll go back into this top level project and we can imagine that we have been working on a new requirement. We'll filter down and and look for requirements that are actually new or changed. And maybe I'll I'll just filter down, and we'll get that specific requirement we were just looking at in Plarium. So that's, this pato, oh, pato five one nine. There we go. Okay. So in this case, was it looks like there hasn't been necessarily a change, but we'll go ahead and create an additional software requirement off of it. Maybe we're adding some additional functionality, off of this particular item, this particular system requirement. So I can open up the assistant, on the Ketryx side and write something like, you know, write a new requirement or auto five one nine to add support for, iOS. So we go ahead and you'll see here that we've specified one of the the IDs for a requirement that lives up in Polarium. And the the goal here really is to give, an AI system which can be supported by an internal LLM, one of your internal LLMs. Access to the context to all of the different life cycle systems that are used within the product development process. And we can not only analyze that context, but also create items and push those items into a system like Jira. So you can see that we've created a particular item. It's gone through and shaped this requirement for us. And then we can go ahead and create and push this item directly into the system where it will then be actioned on by a team, For example, by pushing this requirement into Jira. I can go ahead and click suggest and see if there's any relevant requirements. There might need not be any relevant requirements yet to the the iOS support. And it looks like we have another question here on, the let's see here. So the question was, as teams trace stories to code and to testing over time, can Ketryx help recall tests that may may be deeded in the future when additional code changes in the same area are made? Okay. That's an excellent question. So it's the answer is is yes. But let's go back to the traceability matrix and talk a little bit about that because that is slightly different than the answer that I gave earlier. So the question is really around how can we understand based upon changes to our code, tests that may need to be rerun. And the challenge here is that it's not just about identifying maybe those unit level tests that may may need to rerun. Maybe those are rerun anyway every time the the code is built, but also those, system and integration level tests that that might live in Polarion. And so what we'll see is that for a particular item so this particular item is a JavaScript annotation. And for the particular JavaScript annotation, it can be traced up to a a higher level test, a test that may live in Polarion. And that means that when this particular section of code is modified and therefore this particular software item specification needs to be re reviewed and reapproved, you'll be notified of the tests that are downstream from that specification that either may need to be rereviewed and updated or at a minimum reexecuted for that particular release. So I hope that that answers that question. Also happy to find time after to go in a little bit more depth. But the the regression, yep, the regression analysis use case is, is a strong one, particularly for the for the Git integration. Alright. So let's get into the release area for this particular project. And what we'll see here is a release area that centralizes all of the approvals that need to be executed across different systems as well as the different process steps that need to be followed for your, you know, particular, quality management system. So we can configure this release checklist to match your procedures. We can develop a set of milestones, which are phase gates that need to be executed before we move on to the next phase of the process. And then when it comes time to documentation, we can go into the documents area, click generate documents, and we'll go ahead and pull all of the relevant controlled records no matter what system they are managed within. So in this case, it will pull our system requirements from Polarion. It'll pull work items from Jira and items directly from the code repository. Downloading one of these documents will show us a default template for how we can pull this information into a Word document. We can configure, these documents to to match your particular, templates. And same is true when we talk about, traceability matrices and the ability to to build that kind of, oh, one second. Let's open up the right document here, Including information on traceability. So we'll also we'll see not only the content from a particular item that's been pulled in, but also the ability to to present traceability, however you would like, whether that's in a kind of Excel, kind of sheet format, or directly within a system requirement specification. Alright. So let's see here. I I think the final step and and thing that we wanna cover is to talk a little bit about some tools around the AI agents. And we talked initially around how we can utilize this assistant from a more interactive perspective for drafting requirements, drafting test cases, asking questions around our quality management system, or how the the Ketryx platform can be configured in additional ways to accelerate your release. But we have a an a module down here, which is our set of agents. And these agents have access to all of the content and can be configured with both a prompt as well as a filter for specific data that can be pulled in. So if I open up this prompt here, we can see, the ability to to offer one of those system prompts for analysis along with a filter to select particular data from different systems to be analyzed. We have a set of templated agents that come with with Ketryx, all the way from the ability to detect comp conflicting requirements. For example, conflicting requirements that are currently managed in Plurian today, all the way down to a number of expert quality review agents that can enable you to get closer to that right first time review process for anomalies, change requests if you use that type of item, and requirements. And what these results look like, after they run each night would be a set of, recommendations. So it's not necessarily just a report that you read and then action. It provides actionable changes to to records. So in this case, it might suggest additional traceability, from a particular test case up to a particular, requirement or or specification, whether that lives in Jira, Polarion, or in this case, it's actually recommending a a trace up to an item that's being managed in in ADO. Alright. There's a lot of other modules that we can explore in Ketryx, that we won't have time for today, all the way from how we can centralize risk management, whether you're if you're managing, risk across multiple systems, how we can manage the software bill of materials, and provide traceability from the SEWP components to the cyber and safety risk management process as well as any validation activities that you do for your SEWP. In addition to tracking the SEWP, of tracking of the associated vulnerabilities and the process that those vulnerabilities go through to be mitigated, or I guess risk assessed, mitigated, and then finally, go out in a in a release to to get that resolution. So there's a lot we could we could cover here, but I think this is a good good introduction to kind of how these tools work across, and we're able to to manage that life cycle in a holistic approach. So I'll go back up to the slides here and skip down to to a bit of a summary, and then we'll introduce, the next webinar that's coming up. So as we we covered, what we find today is that teams are are managing the life cycle of software across multiple tools. That includes Polarion or or even Ajama, as was mentioned in the q and a, down into software development life cycle tools like Jira and Azure DevOps, GitHub, Bitbucket. A lot of documentation is being done in these tools and manually synchronized up into Polarion. What Ketryx does in working in tandem with an existing Polarian integration, or Polarian system is how to synchronize both that data and the process. Now, with that, I'll I'll pass it to Yolani to introduce our our next webinar that's coming up. Thank you, Gabriel. Thank you for your time, and then thank you for everyone for attending this webinar. We'll do q and a in a in a minute, but, we wanted to invite you to our next webinar. And so on Thursday, June twenty sixth, we will learn how Beacon Biosignals, a leader in AI and MedTech, secured two of the FDA's forty four PCCP approvals in twenty twenty four. So we'll unpack how they use PCCPs to ship AI driven software updates biweekly without compromising compliance. The team here at Getrix is here to help you accelerate your total product life cycle for AI enabled devices. Feel free to stick around for more questions. And, if you need to leave, there will be a short survey, to give us feedback on today's webinar. We would really appreciate your feedback. Thank you again for attending.