---
title: "Jira for IEC 61508 - Functional Safety for Robotics and Physical AI Teams"
type: webinar-transcript
publisher: Ketryx
source: "https://fast.wistia.net/embed/iframe/bk56fwk0w6"
content: auto-caption transcript, proper-noun corrected
---

# Jira for IEC 61508 - Functional Safety for Robotics and Physical AI Teams

*Ketryx webinar — transcript of the recorded session.*

[▶ Watch the recording](https://fast.wistia.net/embed/iframe/bk56fwk0w6)

---

Welcome, everybody. Thanks for joining us for this webinar about IEC sixty one five zero eight for Jira and how to develop regulated products under IEC sixty one five zero eight in developing tools like Jira and Git and many other systems we're gonna talk through with the lens of how it's done in in Jira. My name's Erez. I'm the founder and CEO of Ketryx. With me is my cohost Gabriel, a head of product.

Gabriel? Yeah. And I would say it's it's really exciting to to do this webinar. I think going to the parent standard of six two three zero four and two six two six two is is gonna be really fun for us to dig into, and six one five zero eight is a big one. I know a lot of teams are contending with the complexity of not only building products to the standard, but generating the evidence required by the standard.

Yeah. And I feel like similar to six two three or four, now when you go to the parent standard six one five zero eight and start to talk about traceability, risk analysis, software safety risk analysis, and in some way, a very a very deep and thorough understanding of that. The way that they're thinking of when you should use formal methods, when you shouldn't use formal methods, how does that interact with the risk management of the product. You know, there's a lot of people who love six one five zero eight because it's so self containing. It's so complete in a way that makes it very easy to work with.

Very, very exciting. And I you know, a lot of questions we hear is just how do you generate documentation to meet this? How can I make sure my process is allowed to meet this and I'm recording enough evidence to do that? How does this interact with quality systems overall? And the biggest one is how do you produce traceability for real world products that are built in twenty twenty six, twenty thirty, and are kind of so complicated, so sophisticated, so software driven, and still need to meet all these requirements.

I think that's the main thing we're gonna talk about today. And so just to get started, you'll get the recordings and these slides after the whole presentation. There is question answering. There's someone helping us in the background, so please feel free to answer questions throughout. And there's gonna be a feedback survey at the end.

Please please fill that in. That helps us a lot knowing what other content to develop and how else to help. So like I said earlier, my name is Erez, founder and CEO of Ketryx. I used to work on development tools like Mathematica and Wolfram Alpha, and then I went to lead AI ML for a large biopharmaceutical company called Amgen where we had to develop a lot of regulated software, a lot of software that required proof of functional safety and evidence of process control. I then went to MIT and started this company out of MIT to really help people who are building safe, innovative products do that faster and bring life saving innovation to market faster.

We're quite commonly used in medical devices and pharmaceutical equipment, clinical trials, and now more and more in physical AI, in automotive, and robotics, and industries like that. Thanks, Erez. Hi, everyone. I'm Gabriel Pasquale, the head of product here at Ketryx. Spent all of my career in safety critical systems, beginning at MITRE as a principal investigator focused on embedded system security.

Like, even my initial research was focused just on software countermeasures for for safety critical systems focused on cybersecurity. I carried that thread through to Amgen where I applied more, I guess, advanced natural language processing and AI techniques on the quality and reliability side of the house for manufacturing. The connection to to life sciences is what brought me to to Ketryx, and I've been here for a number of years. Excited to dig in and really walk you through the core sections of six one five zero eight and how teams are using modern development tools along with Ketryx to streamline compliance. So why are we here?

We're here because physical AI is accelerating everywhere. We've seen it in factories. We've seen it in hospitals. Now we're gonna see it more and more on the road, in the home, more and more automation. There's so many companies now deploying automation to, like, industrial settings.

There's so many more companies building now a different form of robotics, humanoid robotics, wheeled robotics. Many different medical devices coming to market, including a lot of robots already in the surgical room. And a big question is what happens if these systems fail? How do we make sure they're safe? Well, that's done through standards like six one five zero eight, which is a functional safety standard that helps make sure that basically software used in the real world, AI driven software, is safe and reliable, and we understand kind of what it can and can't do and shouldn't be doing.

And we have processes and practices to ensure that the things it shouldn't be doing, the risks, are controlled by risk controls. And, basically, in each version, we verify that those aren't getting to market to consumers. What's a really big challenge with physical AI is that unlike kind of old school factory software, physical AI is ever changing and adapting. You wanna constantly update systems and have it learn from more and more experience. And as a result, you need to have a really sophisticated approach to validation, traceability, quality assurance, and ways to ensure your systems are functionally safe for consumers.

And what's the the problem with that today? The problem with that today is that all this different information about compliance and safety, which is cross functional in nature, which asks, did the product people or engineering people and risk management folks and quality controlling controlling testers, have they interacted in the right way and make sure that this feature, the way it works, and the way consumers are about to use it, that it works correctly and is safe of harm. And so one of the hardest questions is how do you coordinate processes to make sure that information is shared cross functionally and people are learning from it, but also generate documentation that the right decisions have been made by the right people in order to ensure functional safety of the product. And as systems become more and more AI driven, this only gets worse because everything is accelerating. So both the rate of change and the surface area of change.

So many more systems are AI dependent, and so if this has been a problem in the industry for a long time, all these different tools and the way they work, now because of the rate of change and the kind of increase in the feature space we're working with at each change moment, there's so much more work to do. Yeah. This flexibility of these AI systems means that you can apply them to new use cases easily. And as you apply them to new use cases, you need to consider the safety of that application. Like, I'm trying to think, Gabriel, what are the one of the most common questions we get from folks who make robots?

It's like, how do I make sure that it's also safe for this new use case, for this new intended use, for this new market I'm going for? And how do I generate evidence, by the way, of that even though I'm in multiple markets or in multiple jurisdictions or create multiple types of products for health care, for industry, for cars? I think all of that is a great question. How do I get really certified to that by existing and notifying bodies? And I think that that it's a perfect lead into the next slide because we think, you know, we've worked for quite a few years about this problem.

We think there is a good solution to this, and that's what Ketryx is. The Ketryx is an AI native product development platform that allows you to interconnect your existing systems, generate evidence of compliance, and enforce your processes like documentation processes, traceability processes, under types of milestone based processes in order to create safe innovation and safe products for people to use while you're updating very frequently, every day, every week, every month, and so on. And this is kind of the agenda for today. So we're gonna talk a little bit about what I c five zero eight is, what it requires, where's the challenges with Jira in this kind of domain and in the age of AI systems for this use case. Then we're gonna talk about how AI changes both the product itself, but also the workflow to make the product and how to, like, create and bring things to the world.

And then how does this work in Jira and tools like Jira in order to both complement modern engineering and make it compliant. Really quickly, just to look at six one five zero eight, you can think of it as having four main requirements, risk management, traceability, after development processes, after modification processes, again, that change element. So from risk management, you can think of sections that talk deeply about, like, understanding what software is related to hazardous events and and risks, and how can that happen, and how do you need to describe the software well enough as part of your software development practices in order to ensure you can put it under control and you can check that different functional safety controls are met in every version. That's a really core concept that we're gonna talk about is how to develop it in a way that's automated. Traceability, of course, is always a deep topic in highly regulated, high reliability systems due to the nature of the products we're gonna discuss and the complexity of those products and how many systems and subsystems they have and how much of that is software driven, both firmware, cloud based software, other kind of different mobile apps, iPads, and so on.

There's a lot of complexity in that, and to think of how do you wanna both structure your traceability to be ready for change and maintain kind of compliance with traceability requirements and generate that evidence throughout. And the software modification, I'll let Gabriel discuss a little bit more. It's one of his favorite topics, but this is kind of how do you bring this all together all the time. Absolutely. And I'll say that there's there's one other section.

You know, there's there's a lot of content for us to get through today. So so one of the sections that we did leave out, but we have lots of other great resources and and capabilities within the product, is for preexisting software. So aspects of your software supply chain that you don't necessarily develop in house, which is another key challenge when you're developing systems that are compliant to the standard. How do you manage aspects of the software that are not under your control? So we have lots of great resources on that on Ketryx dot com, and we won't necessarily be covering that today, although it is certainly something in scope of the platform.

Yeah. And definitely, I think a big point of thought for folks wanting to sell into EU with the EU Cyber Resiliency Act and the different kind of industry based SBOM Acts in the US. So I think we'll start with one question and a quick survey, which is what is your biggest challenge using Jira today for product development? We'll let people just have that come up. Please press in.

I see already a good portion of the audience is in, so thank you all. We'll just give it another kind of thirty seconds here. We'd really appreciate the folks participating. Okay. Pretty great.

We're about at seventy percent. We'll give another, like, ten seconds and close just to see if we can get some last folks in. And that's really helpful to understand exactly what people wanna talk about. Okay? Okay.

Great. This is pretty interesting. Like, I think folks can see that it's pretty typical. Like, there's challenges around documentation, challenges about traceability and risk management, and how to put the different systems under control. And so I think that, Gabriel, most of the content's gonna hit this really well.

Absolutely. And I think that's a great segue into our our next slide, which but today, we're talking about Jira. Jira is a great tool for agile development. Without some additional work on top of Jira, it's challenging to use it for functional safety evidence. And although we're gonna spend today on Jira, there's a lot of systems that are involved in your software development, product development life cycle, and it's a very similar story with these.

How do we bring them all together? But just like we saw in answers to the poll, these are the challenges when when it comes to an assessor, internal or external, looking at your evidence. Can you effectively trace every safety function? Can you effectively trace from the change that you wanna make through the how it ripples through your documentation requirements, a software unit architecture, unit design, and then can you actually pull up evidence for all of this when the assessor asks a specific question or wants to follow one of those things? And by assessor, we mean someone who is auditing you to the standard.

Right? Internal or external. And then by evidence, we mean kind of written usually in in PDF, Word form, Excel. It can also be in, like, databases, so to speak, that have validated interfaces. But most commonly, people just produce Word and Excel files to meet this.

Absolutely. And all of this evidence needs to come together into a coherent safety case. So that final perspective that you're giving to prove that you have developed a a product that's that's safe. And the safety case, you know, I think that there's a lot of great parallels both in medical devices and other industries, but it's really an assurance case that explains how all the different aspects of this product, its use case, the different risks it has, the different testing you've had for it, the different methods you've used, and the different processes you have in order to make sure it's safe through kind of a logical claim of all the different other pieces of evidence that we created along the process. This is kind of a core idea.

Right? That every version, there's a way to explain why it's safe and compliant. And the challenge is that this evidence, as like you're saying, you do want to leverage the tools. The tools are where the evidence comes from, and one of those tools is Jira. And one of the challenges with having your evidence come from Jira, cover all of the the survey responses.

Traceability isn't enforced across the systems that are involved in your life cycle. When you make you know, when you're conducting a change impact, you can't propagate that across all of the different systems that different personas and stakeholders use within your life cycle. And you need to manually, oftentimes, assemble this evidence into that coherent assurance or safety case that you ultimately present to an assessor. So often, you're you're relying on a process, or humans in this case, to enforce that the correct evidence is being collected and the correct process is being followed, rather than having a system help you guide guide you through the through the life cycle. Before we dive in to the specific sections and show this live within Ketryx and Jira, I'll hand it back to you, Erez, for just a few notes on on how we've helped teams with this specific problem.

Yeah. Thank you, Gabriel. Really wanna talk about two examples. One is of a large Fortune fifty company. The other is as of a emerging kind of start up y innovator that is coming into the market, into commercialization.

So starting with large company, this is a partner that came to us and said, I wanna build robotic products. They have a lot of software in them. I wanna deploy that in globally and meet a lot of different product level regulations. We worked with them for a few months to understand kind of the structure of the product and the deployment and the regions they're impacting, and then helped connect the fragmented traceability they had that was being compiled very manually and tie that into both safety evidence and regulatory requirements. The pain was that it was so distributed.

Right? Like, they had information in the requirements management system, information in multiple systems of work, other product related information, and and product life cycle management systems, and they need to bring it all together to show that each particular version has all these properties. And what we help them do is develop this AI driven traceability and change impact analysis system that kind of uses Ketryx as agentic AI workflows to run between different systems, understand how the traceability looks for those different systems, and then perform change impact analysis and help kind of do any modifications to the data and the product life cycle artifacts or work artifacts in order to kind of instantiate this change. At the end of the day, they reduced their entire process for safety reviews by around seventy percent, and they're now audit ready as they work through a release and not only towards the end of the release through manual compilation of work. And I think one thing that's important as we've talked about AI here, Erez, is that it's not just kind of our what we're thinking or what everyone's thinking is sort of generative AI here.

You can't trust all aspects of generative AI. So you need to have a system that can bring structure and determinism to the way that you execute change impact, to the way that you document your traceability. We'll get into that later, but just that caveat of it's not just, you know, a chat GPT sort of LLM. There's also sort of this symbolic approach to enforcing aspects of the process. Yeah.

And I think that even the next example even highlights that more because it's so fast. Right? So this is kind of a very different case study with an emerging company. It's a physical AI unicorn. They wanted to figure out how to go from this rather complex, very fast moving release cycle they have and system they've built and how to put that system both under control and validate that validate it, perform risk management, do all the things you need to do, but still allow them to work within their CICD cycle and achieve validated CICD.

So the biggest fear was that going under control and getting ready for commercialization will slow down engineering because the compliance will be very manual and will actually delay getting to market even further. There was an existing formal process for the company. What traceability they were doing was done very manually across different coding tools and requirement management tools and testing tools, and there was a big pressure, rightfully so, to maintain both product quality and velocity. And I think that's kind of a hidden fear that folks don't talk about enough is doing a lot of this work and the amount of labor associated with it can not just impact your product velocity, but take away from you working on the quality of the product. And that was kind of a big point here for the team of how to not do that.

So we met them. We helped them kind of understand how to embed compliance in their CICD pipelines, a lot of connections to Ketryx API and MCP, and using all the tool chain to drive both their Jira, their Git, and other workflows. And that allows them to use kind of AI to generate content upstream changes to traceability documentation, new risks, new risks from the marketplace, from other competitors, from news sources, but then also use symbolic controls to make sure approvals happened, traceability happens as these changes are happening, and then use very formal automation to basically generate all the documentation behind the AI working with the people earlier on in the process. What they got to is this ability to combine both their existing people in in a CICD workflow with agentic AIs, both for coding and compliance, and have this really streamlined workforce that combines people and agents that work very tightly under a quality management system. They had complete microservice approach that had basically dozens of different microservices connecting into their products.

And it was ready to scale because you could change a lot of the intended uses because it was so modular. And all of this was done together in about ninety days. So it was a pretty exciting project and really great team. We were lucky to work with them. What you see from these two examples is really the spectrum of maturity of a potential customer.

So, yes, you know, this team knew how to use and already had an architecture that supported microservices. They had a mature CICD process, but that doesn't mean that there aren't other organizations that are that are farther back on the maturity curve for software engineering, but still have an immense amount of value to gain from just starting with automatically generating evidence. Finding that starting point is something that that we we do closely with with our partners. Yeah. Absolutely.

Well, Gabriel, I'm so excited for you to take these, both of these examples. If you're coming from a very large company trying to understand how to adapt to this world, or if you're you're building a new company trying to understand how to adapt yourself to this world. I'm just so excited to see what you're gonna share. So thank you. Yeah.

Absolutely. Thanks, Erez, for the intro, and we'll actually jump straight into the demonstration. I promise there's only four slides. Before we jump into the platform, we'll talk a little bit about risk management and traceability. So two slides, then we'll get into the platform.

When we start with risk management, I think this this feels very natural. This is where it begins for all robotics and physical AI teams. Now, this will look slightly different for every team, but the pattern is is generally the same for teams that are leveraging Jira or another sort of developer focused tool for documenting and and running the development process. Teams will take hazards that you identify during the analysis activity. You'll create Jira issues for them, and then often track risks associated with them, either in a spreadsheet or potentially through a customized schema on that ticket type.

And then when changes happen, this is where oftentimes, you know, you'll have some external documentation, but you'll check you'll kick off the change process in in Jira because that's where everyone's collaborating. Now the challenge, I would say, more broadly with doing this in in Jira and with these specialized configurations of Jira is that it's hard to propagate that change across systems, across people that you're collaborating with, and then ultimately produce the evidence of that change into a final set of documentations. And the other piece, which is becoming even more challenging with these systems that do get an immense amount of feedback from the field, is the life cycle of your risk management process is needing to accelerate. So more use cases, more data from the field means that you need to continually reassess the risk of your product and ensure that your tools and your process can keep up with that. So when we talk about where this approach breaks down, that's really the three common areas.

Propagating change, maintaining the the controls and documentation across systems, and then making sure that you can address that that data from the field fast enough in your risk management process. Now risk management is tied maybe that's a that's a joke there, tied very closely to this concept that we know and love, which is traceability. The idea that you need to be able to trace from that risk all the way down through the controls that control that risk, and finally, the evidence, verification evidence that that control is implemented properly. Now how teams today do this within Jira is typically leveraging the Jira native links to create traceability. Oftentimes, when we cross into other systems like Git or the code, we are maintaining manual links or developing internal automation.

For producing documents, we'll find ourselves using Confluence or maybe some additional plugins that come with Jira. And then finally, oftentimes, the evidence generation and approval is done outside of Jira. The challenges really come down to maintaining the traceability. If you have externally produced evidence, keeping that in alignment with the system of work becomes the main challenge. And when it comes to evidence gathering, that means now we have evidence spread across tools, documents, systems, and that becomes very challenging to bring all together.

Now let's jump into Ketryx, and we'll go through a quick intro before moving on to the software development and software modification sections. So let me switch over, and we will transition into the Ketryx platform. I'm actually gonna start on the project's dashboard, which gives us a good overview of the different projects that we're working on within Ketryx. So on the project's dashboard, you can see we have five different projects that we're working on. Looks like we're working on a humanoid robot that is compliant to six one five zero eight.

So Ketryx allows you to manage, in this case, a quite complex system as multiple projects By allowing us to break down our system into a set of subsystems, it allows our team to iterate independently, test test independently, generate and collect evidence independently, and ultimately release their subsystem at different rates, a key aspect of allowing our teams to move in an agile way. The second thing you'll see here is we do have a standards project. So whether you're complying to six one five zero eight or two six two six two or producing evidence for a particular regulatory region, we enable you to trace these requirements and ultimately produce the specific evidence you need off of the same underlying product level compliance evidence, like requirements, testing data, risk management. Going into and we're actually gonna choose our our system of systems project here to to investigate. We'll be met with the all items screen.

And this item screen shows us all of the different task level activities that are being taken place across different systems. So I just filtered down for us to see all of the different activities that are happening across different systems. That first one is actually a testing system. So Test rail, where our verification and and QA folks are are working on testing the robot. But we also see that we're integrated into Jira as well as IntiGit.

So this is how we're bringing all that information together into one place. Now, challenging to see this all contextualized into a list view. So let's actually jump into traceability where we'll cover risk and traceability management. I will first collapse that collapse that sidebar, and now what we'll see is a traceability matrix starting with a risk on the left side, flowing down all the way to our test evidence. And if I click on one of these bead icons here, I can see how this risk flows through the rest of my requirements and ultimately down to that testing information.

This is an example of a of a quite simple v model of risks through system, subsystem, design, and testing. We have folks that are managing many tiers, you know, up to five, six tiers of requirements, as well as software unit design and and unit architecture. So this system is is developed to be configurable to the complexity of the product and architecture that you need to support as you are compliant with six one five zero eight. Now what you'll see on the right side is something that can enable your teams to accelerate a lot of the identification of issues and remediations of those issues within your requirements and tests, and that is the AI assistant. Now, before I jump into the AI assistant, like I qualified before, it's not just about applying generative AI.

It's about leveraging the structure of information and deterministic automation to ensure that your processes are met. So when we talk about traceability and we break it down into completeness, correctness, and consistency, when we talk about correctness and completeness, these are aspects that are quite deterministic. We can verify through deterministic automation that we have traceability that flows through our v model all the way down to testing. But when it comes to ensuring that the documentation is is consistent or our requirements management is consistent for that matter, that's where having a generative component to our system can help significantly. So one key question here that an assessor will have is does the test case here truly test the requirement?

Is there a case where maybe a parameter documented in one of the test cases is misaligned with one of the requirements? And I've actually run this safety trace prompt here in a in a separate session that we'll look at. But what you'll see is when we execute this prompt, the AI assistant will launch a set of agents that will go through and ensure that we not only have the proper tracing among our items, but that semantically or qualitatively, things are documented properly. So as you can see, it's searching through a set of product projects, found a set of projects that it wants to investigate. Before we watch the agent run for a while to to analyze the hundreds of requirements that are placed in this system, we'll go into a previously run session, which is this emergency stop traceability audit.

And as I expand this, what we'll see is a focus on a few different things. Just as a reminder, we ask the assistant to assess the traceability for the emergency stop safety function. It's not just looking at whether there's an item within the chain, but whether the content of these items actually satisfies the requirement. And what you'll see is it found a set of findings that we can review. And I think that the second and the third finding are the ones that are particularly interesting that aren't necessarily represented just through the structured traceability.

And this is that one of the requirements has a different parameter than the test case that's testing it. So in this case, the requirement says less than a thousand milliseconds, worst case, but the test case talks about five hundred milliseconds. Now in the best case, this is caught in verification and causes a new round of formal verification. Maybe the assessor catches it. I think in the worst case, we go through verification, the assessor misses it, and then we deploy a product that has one, a requirement that is implemented in one way, but tested in another.

So that's one way in which we can leverage the AI alongside more of these deterministic controls to ensure that our documentation is complete. Before jumping back into the demo environment and specifically into Jira, let's cover a little bit how we satisfy the sections six one five zero eight focused on software development and software modification. Very similar to how teams are doing risk management, when we come when it comes to architecture and design, teams are managing these often as item types, either the default item types with epics and stories, or they're creating sort of additional custom work items, as well as leveraging Confluence for this documentation. We often see custom fields, plugins, or spreadsheets that are tracking the safety integrity level constraints for those particular components. And then finally, when it comes to testing, we'll see tools or plugins like X-ray, Zephyr, or external QA tools like TestRail.

And I would say, you know, across the the spectrum here, oftentimes, the challenge becomes tracking all this information, ensuring that the process has been met for each component and that we've have considered the constraints. And then finally, piecing together evidence. We integrate into X-ray. It's an excellent tool for testing. For teams that are using TestRail, another external tool, we integrate into those as well to allow you to to automatically collect that evidence and produce that end to end traceability of the software development process that you need.

Now I think, you know, with plug ins, a lot of configuration and focus, you can you can get a system together that manages at least the current state of your project. Now I think that the the challenge really comes down to when we start to talk about software modification is how do we take the current version that we're working on and work on the next version, or work on the next three versions in parallel, testing them in parallel. This is where, really, we start to see breakdown of of leveraging a tool like Jira on its own for managing the the life cycle and the documentation. Oftentimes, these changes are documented in comments, subtasks, oftentimes lots of different ways of of developing Jira automation to support the change management process. We've seen we've basically seen it all.

And, ultimately, this comes down to a a complicated configuration of Jira that's that's difficult to maintain over time. Teams are often reverifying evidence. Evidence is becoming out of date. And tracking all of these states and statuses across not only Jira, but across other systems that your team is using becomes burdensome. So with that sort of stage setting, let's go back into the platform and we'll spend a bit of time circling through a specific change that we want to assess and then see what that looks like on the Jira side for our folks that are executing aspects of work in a particular tool.

So back on the traceability screen, I'm actually gonna filter down for a specific requirement that I know we made a change to for demonstration purposes. And I'll open up this requirement over in Jira. What we'll see is a work item in Jira that's been configured to meet IEC six one five zero eight. So we have the aspects of documentation, fields that you need for this particular standard. And within the particular work item, you'll see two additional panels that have been added by Ketryx.

The first is an approvals panel. So we're providing sort of an complete complete history of all the changes, as well as enabling you to execute approvals with e signature, if that's required within your process. And the second is we have this traceability graph. What this shows is the relationship between the current requirement that we're working on and other risks, requirements, test cases that are within our life cycle. What this allows us to do is understand the relationship of this requirement against others, whether or not those particular items exist within Jira.

As you can see for this particular solution that we're looking at, this particular requirement is tested by a test case in TestRail. So allowing your teams to use their preferred tool while still allowing a centralized view and centralized evidence generation. So now that we've looked at traceability within the within Jira and how we can enable our teams to continue using their preferred tools while continuing to do approvals, continuing to build that traceability that the documentation needs, we can go back into the trace matrix on the Ketryx side and understand again how to apply not only more of this deterministic impact analysis approach that the traceability matrix provides you, but how to leverage an AI assistant and a set of agents to do some of that change impact analysis for you. So configured within this environment, I have an additional prompt that focuses on change impact analysis. And what you'll see here is that the change that we wanna make to this version of the robot is to change this emergency movement shutoff trigger distance from fifty millimeters to fifth sorry.

From ten millimeters to to fifty millimeters. And this is quite a complex change. It's not only going to be looking through one particular traceability thread, but really looking across all of your requirements, detailed design, and testing to ensure that you've properly cascaded and take into consideration all of the impacts of this modification. I will you know, this agent and its sub agents will run-in the background to to do the analysis, but I will go to, again, an analysis that I ran earlier so that we don't have to wait for the agents to complete the job and see what was identified during this change impact session. So I'll go ahead and and open this up to to full screen.

Let's widen it. And what we'll see is it's analyzed that specific requirement where we've made a change. It went ahead and identified five of the different blocking items. Now, this particular output format can be aligned to to your process, your preferred way of working. Now this is a nice simple version for us to grok while we're here today in today's demo.

And what we'll see is it calls out a few different areas. It says, alright, we've updated the requirement, but the new aspect of this requirement has no verification coverage. We have reduced the severity from five to one in terms of residual risk, but that assessment was done at the ten millimeter value, and we need to reevaluate that at the fifteen millimeter value. So a lot of these things that either you're gonna spend an immense amount of time comparing the previously released baseline to the current the current baseline, or you might you might miss aspects of this this change and impact assessment. So, really, this AI system is meant to accelerate the process of doing your change impact assessment.

And each of these reports here can be exported. So in this case, we've exported this directly into the document system within Ketryx, and we could see a complete report for our change impact analysis. We can apply all of these changes driven through the assistant directly into the source system, but oftentimes, it can help to have a report. Potentially, you you push this to to Google Drive, and then you collaborate with your colleagues on understanding the specifics of the impact. Now we went through a lot of detail around traceability, change impact, but ultimately, all of this wraps together into a release.

A release is ultimately the evidence package that you need to produce that you show the assessor, that you show the auditor to show that you have a sufficient safety case for for your product. Ketryx has deterministic document generation. So we have a set of templates that deterministically pulls evidence from systems. Aspects of these templates can support AI generation of narrative sections and other sections that require summaries. But typically, we are configuring a set of out of the box or configurable templates to support whatever standards or regulatory regions you need to comply with.

And when it comes to leveraging an assistant alongside, you could also leverage the assistant for essentially drafting your safety case, or at least asking you questions that would enable you to produce a more effective, more backed, and more evidence driven safety case. Now with that, we'll we'll close out with just a few slides, but I hope this shows you how we can start and center our development process around risk, see end to end traceability from risk to controls to verification evidence, leverage not only deterministic controls within Ketryx, but also the AI assistant agents to accelerate that documentation impact assessment, and ultimately, the release and generation of evidence for your safety case. When we talk about Jira in general, we've listed out a number of plug ins that I think can be helpful. They can support specific aspects of of the process from requirements management through risk and testing. But when you're looking for a holistic solution that will wrap these parts of the life cycle together into one auditable trail with automated evidence generation, that's where we're really focused.

Allowing your team to use your preferred tools while enforcing enforcing the processes you already have in those tools to automatically generate evidence of compliance. And this is just the start. You know, depending upon the product that you're developing, the complexity only grows. Particularly for AI based systems, you don't just use one system. You don't just use four or five.

You often have ten, twenty different systems that you're using to develop your product, and ultimately, ten different systems that contain evidence that need to that is needed to support your safety case. And this is just the beginning of how do you effectively manage the life cycle of your product, not only from an engineering perspective, but so that you can effectively pull and complete that compliance deliverable. Now with that, we'll conclude today's webinar. Thank you so much for taking time today to walk through six one five zero eight, how Ketryx can support compliance to six one five five zero eight, allowing your teams to move faster while not missing any particular process step that would, I guess, threaten the safety of your product or the accuracy and clarity that your evidence provides Alright. Well, good to see you all.

I'll jump in here. My name is Dennis. I am a solutions engineer here at Ketryx. Looking forward to continuing this conversation. I actually come from a a robotics background a bit, and here at Ketryx help teams kind of understand what Ketryx is, like our philosophy about how we go about regulated product development.

And I think we'll spend a couple of minutes here taking any more questions that you might have. So feel free to keep throwing those questions in the chat, and I'll monitor the chat here as well for for anything. Alright. Let's do this. Alright.

I believe my screen should be good there, and let's jump into this. Thank you, Joe. Alright. So this will be very familiar to to those of who have been following along the last few minutes. Thank you, Gabriel, for for walking the team through here.

And there's a couple of things that I think could be helpful to dive a little deeper in, potentially on the you know, now that we are having this live understanding of the work that our team is doing in, in Jira, in our testing tools, in Jama, whatever those tools may be, first is, you know, how can we use this as a as a modern way to manage our our cybersecurity, our dependencies, our vulnerabilities that are associated with our code base. So I think what we'll do is we'll start there for the next couple minutes and then kinda jump into, a a different angle, which is how do we generate the documentation associated with, with this work that's being done. So as a reminder, what we're seeing here at this top level is this humanoid robot, which, again, we're calling a Systmas Systems because it is, essentially this architecture that is combining a few of these other systems here, this hardware system, this software subsystem, as well as some of those six one five zero eight standards. And we'll see that this software system, is connected to a a GitHub repository. And what we're doing here is pointing these pointing the software up into this system of systems.

So I'll click in here, and we'll see directly those items here, those GitHub items. And, typically, what we see is teams managing, dependencies in their code base. They might have a a service level understanding of of what is there and the kind of requirements associated with managing those Git based, that Git based information. But what typically happens is we see teams, you know, spending a lot of time manually gathering and managing those dependencies, performing assessments on those dependencies, and ultimately generating the documentation needed in six one five zero eight to to prove that we have full control over what's happening in our code base. So what I'll do is I'll jump to what we call this SBOM module, software build materials.

And what we'll see is the list of dependencies that Ketryx is scanning directly from your code base. So this is I also highlight that we do pair well with, code scanning tools like Snyk or Black Duck, that your team may already be using. But, really, what Ketryx is helping fill in the metadata associated with these dependencies that ultimately go into generating your SBOM. So I'll sort of start at the end here, actually generating that document, and we'll see a couple tabs are open up. And and, really, what we'll highlight is this tab here, which, again, this is the endgame.

Now that we have an understanding of what's happening in our repository, we can generate this software build materials at any time, which is gonna include a lot of information that six one five zero eight dictate dictates that you need a full understanding of. We'll see risk information. We'll call Pearl information, URLs, intended use. And we'll start to see that Ketryx is essentially tracing this dependency back into the design controls that are the product itself. So back in here, we can kind of take a couple clicks deeper into what we're actually doing with these dependencies.

And similar to other types of items that Gabriel was talking about, like requirements and test items, we treat these dependencies very similar as these nodes of information. And what that allows you to do is similarly filter manually, or we can talk about how our agents can perform these tasks. We'll filter manually to maybe dependencies that have higher critical severities reported against them. So we'll see this list here that's being, you know, directly pulled from our code base. And now clicking in, we'll start to see some of that metadata, that meta information that we need to associate with this dependency, in order to generate our SBOM.

So here, we'll see, a a kind of template of what the information is, And the next step would be to, you know, help have Ketryx help us fill in this information automatically. But for the purpose of the demo here, I'm here to just highlight that Ketryx is really purpose built for this type of management. So these security impact assessments, level of support, end of life, this is really an empty template to say, Ketryx, now that you understand what should be associated with our dependencies, go help us, run an agent and help us fill this information out. And then kind of moving downstream, it looks like this this, this dependency itself is is scanning and not finding any vulnerabilities, but what we'll see here and maybe I'll I'll jump back to find one with automatically from the national vulnerability database. So this list will this list will get updated automatically with, let me jump back so we can have a little something to look at there.

That list will get updated automatically as vulnerabilities are being reported, against those items. And, ultimately, again, the goal is to say, now that we have full control over our dependencies, the vulnerabilities associated against them, we can have full control over our our software build materials itself and generate that document at any time. And the last thing I'll touch on here is on this release dashboard, which is, just highlighting the versions of our product that we're working on. What I wanna do is highlight this monitoring column. So as we deploy different systems or different deployments of our our our robots, into, you know, different fields or or different variants, the Ketryx really, the infrastructure of Ketryx will allow us to monitor different the vulnerabilities being reported against those different versions.

So as we use different dependency packages across versions, Ketryx is really gonna help us manage you know, maybe we have ten versions of our software out in the field, each using different sets of of dependency versions. Ketryx is gonna allow us to manage all those different combinations without having to manage, you know, manually that through Excel documents and and other documents that you may be using today. And I guess I'll I'll continue down this release management path here just to highlight just to highlight a couple more areas that we build this software dependency into our release management, and then we can touch on kind of a full design history file documentation as well. So what we're seeing here again, and I think Gabriel covered this pretty well, is, a high level report card, or I guess I'll say a detailed report card of how close we are to releasing version two point o of our product. So across the top, we'll see a team potentially working in a waters from fall approach where we wanna build stages or specific documents into the release segments of our product.

Here, we'll see an AI generated summary of exactly what work needs to be performed, in what tools, by what individuals. We really wanna surface direct signal to your team as to what needs to be worked on for this version. And then finally is that release checklist, which I'll reiterate again is is really a a computational way to enforce your quality systems. And a couple things I'll highlight here are this this dependency check. So, again, we really wanna pull in your dependencies and your vulnerabilities into Ketryx, manage them in a way that we can computationally enforce that we are, you know, managing them accurately and correctly, that we are tracing these dependencies to risks that may arise, that we're managing those risks.

So it's really the full life cycle of our software management. And and then we'll see things associated with our documents here. And I know Gabriel touched on this a bit. So our documents are actually up to date. But what I I'll still do is is jump to this document module where we can see not just our software bill materials there, but also the other documents that we have this live understanding of, related to, you know, related to our product.

So our design specifications, our hazard analysis, etcetera. And by having that live understanding of what's going on in our development tools, we can now, through a validated connection, allocate that information into these documents and be able to provide a full set of evidence at any time. And not only is is Ketryx comprehensive, but the idea of regulated product is, is comprehensive itself. And I say that as kind of a leeway into, into our AI assistant. And what So I can use this assistant, like Gabriel is doing, to, you know, perform change impact analyses, check our check check our safe our our trace matrices.

And but, otherwise, like, I'd like to use this assistant to just kinda understand, you know, help me understand best practices, of, you know, dependency dependency dependency. Probably spelled it wrong. Management, you know, related to our quality management system. And this really can also just be a tool to help understand our own processes as they compare to maybe best practices. And then, specifically, as, you know, work arises, you know, compare and and, help Ketryx navigate me through our quality management system, through the tools that we're connected to, etcetera.

Alright. Looks like we're getting one question here. Gabriel talked about Ketryx being applied to physical AI. What applications are there for Ketryx across therapeutic areas? Does one space naturally fit Ketryx better than others?

That's a great question. I I, what I like to say is that Ketryx is, agnostic to to industries and to standards. I myself actually come from the more of a robotics and kind of physical AI world. I look at Ketryx as a theorem prover, which which is a a a fancy way of saying, as long as we can verbally or in text explain the processes that we want to enforce, Ketryx's goal is to take those processes and build them into computational symbols and computational checks in the platform to be able to prove that you're following those checks. For example, with the idea of traceability, one theorem is that all of our risk controls are being controlled by system requirements.

That is something that's heavily related to to software development as as well as hardware development. And so to answer your I think to answer your question, we have many of our partners are are in the the therapeutics world having to follow medical standards like ISO sixty three zero four as well as, more functional standards like, like six one five zero eight. So I I say just like how the system of systems architecture allows you to build in this kind of system based architecture, I'd say Ketryx equally allows you to build in these cross standards this cross standard functional cross standards architecture where you have a a full and independent understanding of how you are of how you are fulfilling both standards like six one five zero eight as well as maybe a medical standard like sixty three zero four or one third one three four eight five. And always happy to to dive deeper into specific use case. So thank you for asking the question, and feel free to reach out.

I can go into more details with you on your specific use case. Alright. Well, I I think, again, always happy to to dive deeper into platform, kinda play around with our with our AI capabilities. So I really hope that, you guys enjoyed the the webinar. Hope I was able to add some extra color here specifically to software management.

And then, you know, similar to this question, always love to dive deeper on the hardware side of the house as well and how they connect. I think the last thing I'll leave us with is on this system of systems traceability matrix. One thing I am gonna highlight before I let you go is this idea that while these software and hardware specifications are living in those other Ketryx projects, what we're seeing here is our ability to trace those subsystems up into this system level project. So this same logic holds true, and we can see downstream. We'll see those software items and those hardware items tracing back up to this requirement.

And I'll leave this with saying this same logic of how we can build software and hardware together and fulfill system level requirements is the same logic that Ketryx holds when we say, I wanna develop a product that includes, standards from six one five zero eight as well as standards from six two three zero four. It might look different in Ketryx, but the logic is still the same. We wanna enforce that those theorems