---
title: "Git for IEC 62304 - Traceability for Software Design, Unit Testing and Requirements"
type: webinar-transcript
publisher: Ketryx
source: "https://fast.wistia.net/embed/iframe/2d121kbmc0"
content: auto-caption transcript, proper-noun corrected
---

# Git for IEC 62304 - Traceability for Software Design, Unit Testing and Requirements

*Ketryx webinar — transcript of the recorded session.*

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

---

So in the session today, we'll talk about how modern development practices already generate most of the data IEC sixty two thousand three hundred and four requires and where teams struggle to turn that data into traceable and audit ready evidence. We'll focus on how GITs and continuous integration and AI agents can work together to support software design controls, unit testing, and requirements traceability without slowing down to development. But before we get started, let's just do a quick few quick housekeeping items. So first, we'll send the recording and the slides out after the webinar so you don't have to focus on taking screenshots throughout the conversation. Second, please feel free to drop any questions in the Q and A at any time.

We have a team that's monitoring the Q and A and we'll allocate some time at the end to address the most common themes. And finally, we'd really appreciate your feedback through a short survey at the end. This really helps us shape future sessions and make sure we're covering the most important topics. So with that, I'll also just do a quick introduction of our hosts. My name is Yulani Dalla Porter, and I'm a director of client operations here at Getrix.

I work with our enterprise clients to help them accelerate their software innovation while staying compliant. I've spent most of my career within healthcare and medical devices and digital health. Most recently, I worked for a company called Iterative Health using AI for gastroenterology. And before that, I also worked for a large health system called Northwell Health System in New York State. So joining with me today is Gabriel.

He's our head of product. Gabriel, do you wanna do a quick introduction? Yeah. Absolutely. Thanks, Yelani.

Hey, everyone. I'm Gabriel Pasquale, our head of product here at Ketryx. Been helping teams evaluate and understand, implement the product for the last few years, and driving the product vision. I started my career as a software engineer focused on cybersecurity at the MITRE Corporation. I later went on to work at Amgen applying AI for quality and reliability on the manufacturing side.

And it was there that I ran into a lot of the challenges of developing validated AI, validated software systems, and that's what led me to Ketryx. So excited to bring you through the platform today and and show some some new new features and workflows that we've been working on. Thank you, Gabriel. So next, let me do a quick introduction of Ketryx. Ketryx is a AI native compliance platform.

So interoperate your tooling across your various teams and your organization and apply your QMS processes and rules within those tools. Then we're able to use that data to automatically generate evidence of your compliance and to automate your documentation. Now with AI agents, we can also automatically trace requirements, assess change impacts, validate test coverage and flag compliance risks in real time. And so what does this mean for you if you're on a quality team? This means less manual chasing of evidence and more confidence in audit readiness and submission readiness.

If you're on a R and D team, the benefit is that you get to spend more time coding in your developer native tools and not doing manual documentation. So why are we here today? What is the problem we're addressing in this webinar? The problem is how regulated software is developed has changed significantly and traditional compliance work hasn't kept up with that change. So modern teams use Git, CICD pipelines and AI assisted coding tools to shift changes faster and more continuously than ever before.

And the data shows this. Over ninety percent of developers are using AI assisted, coding tools. So this is not just a fringe trend anymore. This is mainstream by now. On the other hand, many regulated teams still spend a huge portion of their time on manual work.

In some cases, it's fifty to ninety percent of their effort that goes into documentation and paperwork instead of engineering and quality decisions. That creates a tension that we see across many of our clients. Fast automated development on the one side and slow manual compliance processes on the other. So today we will talk about how teams can close that gap. How do we turn the data already generated by GET, CICD and AI into traceable and audit ready evidence without slowing down development?

So to make this more concrete, here is how we'll spend our time today. We'll start by looking at the challenges teams run into when they're trying to apply modern development practices like CICD and AI assisted coding within regulated medical device environments. From there, we'll walk through how much of the data IAC six thousand three hundred and four requires already lives in your Git repositories but why teams still struggle to use it effectively. Then we'll share some practical strategies for using AI to streamline traceability, documentation and reviews without losing control. And finally, Gabriel will show how Kedric supports these workflows in practice and help teams accelerate their releases while staying compliant.

So before we go further, we'd like to get a quick sense of the tools you are using within your products today. As you know teams approach regulated development very differently depending on platforms, especially as CICD and AI assisted coding becomes more common and this information helps us anchor the conversation and what's really familiar to you and define the examples we walk through next. So to respond, just open the polls tab in your webinar window, select all the options that apply to your current setup and then submit your response. We'll give it a moment and then share the results in the chat. So, Gabriel, while we wait for folks to respond, from your work with medical device teams, what has changed most about how regulated software is being built over the last few years?

That's a great question. I think a lot of it is driven by the the market today. I think the the big push that we see within organizations is that they need to release faster, whether that's because they they are in a competitive market and they need to get software updates out, or they're developing AI systems. And we all know that for for AI systems, the sort of competitive advantage of using or building an AI system is that you can add more data and improve the product or add more features to the product. So teams that are trying to build these types of applications that require rapid development are facing this challenge that you just described, but it's not every quarter or every half year.

It's they're facing this every week when they need to go deploy. And that has led to innovation both just from traditional automation. We need to pull documentation out of tools, but also leveraging generative AI systems to help draft content and help find the right information at the right time. The last component, which we'll we'll talk about a little less of, but we have a lot of content on, is thinking about the architecture of your product and the design controls that support it. Work that Yulani's done an immense amount with with our customers in thinking strategically around how we wanna change our product and how that influences the architecture of it along with the documentation.

Great. And thank you, Gabriel. So to understand why release cycles are slower than most teams aspire to, it helps to take a look at what happens when medical device development meets the more agile and iterative development practices that enable teams to ship software faster. So let's start with IAC six thousand three hundred and four on the left. This standard requires very clear relationships between requirements, design, implementation, and verification.

And in practice, many teams operationalize this using a V model or a waterfall style approach where progress through each phase results in extensive documentation. So now if you look on the right, this represents how most modern software teams build today. So workflows from a backlog into short sprints with small frequent changes delivering change continuously. CICD pipelines run automatically and AI assisted tools increasingly help generate, modify or refactor code under human review. The friction appears when, teams try to apply fast AI assisted development practices within the regulated environments.

So to connect these two worlds, teams often rely on manual steps like copying and pasting information between tools, documenting work after the execution and performing manual reviews. As development velocity increase, those manual controls stop to scale. And so documentation lags behind, traceability becomes really fragile and compliance work turns into a bottleneck. This is a mismatch between the modern automated development workflows and the manual compliance execution models. So that brings us to the question, if development is continuous, automated and increasingly AI assisted, how do we enforce compliance through systems rather than paperwork so teams can innovate and quickly work without compromising safety?

So the standard is fundamentally about establishing and maintaining clear relationships between what you intend the software to do and how you verify that it actually does it. So on the left side of the view, you define the intent, you start with the use cases, the system requirements and then you move into the software system specifications and the detailed design. At the bottom of the V, that intent is implemented as working software down to the unit level. On the right side of the V you verify and validate that implementation. So each level of design on the left has a corresponding level of verification or validation on the right.

Unit tests verify individual software units, Software verification confirms the software behaves as specified and the system verification and validation confirms the intended use. If you're a developer, most of the work you do every day already maps to what six thousand three hundred and four expects. The problem is that this work is in compliance evidence as is. And what this slide shows is that much of the evidence six thousand three hundred and four expects is already being created as part of your everyday development work, especially inside your Git repository. So starting on the left side of the V where intent is defined, use cases and system requirements often live in issues or tickets, for example, like requirements IDs or linked bugs And commit messages frequently reference those requirements directly showing why a change was made.

And as we move down into software specifications and design, that intent is captured in the architecture document, ADRs, readme's and pull requests. Pull requests in particular often contain design rationale, trade offs and review discussions that explain how requirements are implemented. And at the bottom of the V implementation happens in the source code. The code itself along with the comments and the version releases represents the actual realization of those requirements over time. So on the right side of the V where verification and validation occurs, unit and integration tests live alongside the code in the repository often organized by feature or requirement.

Then CICD pipelines automatically execute those tests and produce logs and reports and results every time the code changes. So when you step back, all of the core ingredients are already here. You have the intent, the design decisions, the implementation and the test executions all captured in the developer tooling and version control. But the challenge is that the data is implicit, scattered and not automatically structures as traceable and audit ready evidence. So this leads to the question, if the evidence already exists in your tools, how do you ensure traceability across it and automate that documentation that IEC and four requires?

So the answer to this isn't necessarily adding more process or asking developers to contribute to more documentation. It's making sure that your data already have three fundamental properties. Requirements quality research often describes these as correctness, completeness and consistency. So we use the same lines here because it maps cleanly to what regulators actually care about when they review the evidence. So let's walk through these three dimensions and look at both the problem teams face today and where AI can meaningfully help.

So starting with correctness, in modern development tests run automatically in your continuous integration pipeline, but the evidence teams rely on is often created later outside of it. So that introduces risk because documentation may not accurately reflect what actually ran on which commit or in which environment. So AI helps by generating documentation directly from continuous integration executions. It can help us summarize test runs, environments and outcomes from the pipeline metadata and tie that evidence back to specific comments and branches with human approval under Part eleven controls. So next is completeness.

Most teams have the right artifacts, but they don't have a view of how everything connects. So missing links between requirements, commits, pull requests, and tests often go unnoticed until the late reviews or audits. So AI can once again help by continuously analyzing git history and the continuous integration data to build and maintain a traceability graph. It can flag missing links, untested changes or orphaned requirements as the work is happening not weeks later during the review. Now finally is consistency.

Intent implementation and verification are often described very differently across issues, commits, tests and documents. And over time those differences can turn into contradictions that are very hard to spot manually. So AI helps once again by comparing requirements, code changes and test behavior across your tools. It can detect inconsistencies, highlight where descriptions diverge and suggest updates to bring design, implementation and verification back into alignment. So across all three dimensions, AI does not replace human judgment.

It reduces manual effort, it surfaces risk earlier and it helps teams keep evidence accurate, complete and consistent at the development speed. So when these properties are enforced systematically, the data you already produced in Git and through your CICD pipelines becomes audit ready by default. So now that we've talked through how developers already generate most of the IAC six thousand three hundred and four data and how AI can help ensure traceability across all of it, I'll hand it over to Gabriel to talk more about how we operationalize this. Wonderful. So, yeah, let's jump in and and talk about how we can operationalize some of these aspects.

And we'll look into a live Ketryx instance integrated with GitHub and Jira, and also jump back and forth a little bit to the IDE. And we won't spend too much time in the development environment, but I do think it's an important context to give for those folks that are thinking about tooling for their team, whether you use the tool or you have a team of engineers that use development environments to to do their work and their documentation. We'll start at the top talking a little bit around how we can leverage documentation from Jira and Git from a use case and requirements perspective, as well as how we're documenting the design of our of our system. Then relevant to capturing change history, how we can capture that code change history automatically, and then proceed onto the right side of the v capturing evidence of verification and validation. We'll we'll talk a little bit about automated testing and how to make sure we're capturing the evidence automatically, including the traceability from those unit integration level tests to the requirements, as well as capturing any test evidence that you don't necessarily wanna trace, but you still wanna capture and have in an auditable auditable package.

Now the two other components that we'll we'll spend some time talking about is how to leverage the AI tools that are available to you, both within the Ketryx platform itself, but also outside of Ketryx, and how we can leverage the context, data, and the guardrails that come with Ketryx to safely use AI in other environments, such as where your developers are working in a tool like Cursor or Cloud Code, any of these integrated development environments, and how, you know, these tools will help us improve quality, ensure that we're right first time in terms of traceability, and that the consistency of our requirements and flow down through those requirements is achieved. So with that, I think we'll first jump to this poll, and then we'll jump into the demo environment and and talk through a few a few use cases. This is a a big topic right now, I think, actually in in all aspects in kind of non regulated regulated environments around how we're bringing AI into our development workflows and bringing more and more AI generated code into our products. So, Gabriel, while we wait for folks to answer this poll, as teams start experimenting with AI assisted development, what's the concern you hear most often from regulated teams? I think I think there's a few.

I think there's the first is around review fatigue. I think that there's there's there's a lot of code that's being developed. And how do we ensure that we have the same level of rigor that comes from these develop development teams that can produce a lot more. And then I think what's really relevant in the regulated space is how do we ensure that we're following our QMS as our development teams can move faster? If no longer the bottleneck is how much software we can ship, the bottleneck quickly becomes how fast can we review, how fast can we ensure that we followed our quality management system as we progress the feature through the pipeline.

So I think I think the concerns are, a, how do we keep up with you know, in in competition? And then second, how do we ensure that we're doing in a safe and and compliant against our QMS way? So we'll jump into the Ketryx platform, and we'll actually just start immediately in one of these sample projects that we have developed. It's this medical image viewer. It's actually built off of an open source OHIF DICOM viewer, which we like to use in in demos.

So it's a it's a pretty built out project in terms of a real system. We have a set of requirements and test cases that have been developed for this open source project. And what we see is many of these objects or test cases, software item specifications, and requirements are all coming from within our source code repository. We'll get into that in more detail, but what you'll see is that Ketryx is this way to connect into commonly used systems like GitHub, Jira, your requirements management systems, and trace all the necessary information across your life cycle. So, yes, we have test cases, and we have lots of our software documentation living close to the source code as this particular team enjoys working close to the source code.

But we also have team members that that work in Jira that are maybe developing use case requirements. Some of the higher level planning is done in Jira. Maybe our risk management is done in Jira along with bug and defect tracking. So here we can see that we're allowing teams that may work in different tools, but all need to speak the same language of I produce some piece of evidence, I trace that evidence, and I need to make sure that that piece of evidence goes through a particular workflow or an approval process. So I'll take a quick detour.

We'll go into Jira because I think that helps ground the the concepts of connecting to a system, and then we'll dig into the Git side and that life cycle. So here's a particular bug that that we'll be working on together during this demo, and this bug lives in Jira. It was reported into Jira and and captured by Ketryx. What we'll see is is Ketryx has configured the Jira environment to have all of the the relevant fields for this particular item type in our quality management system, and ensures that these fields are properly documented both with deterministic rules as well as agents that operate in the background checking the content and the semantics of each filled field. Just like any item in the system, we have an approvals workflow and an approvals widget in the case of Jira that allows us to move these objects, whether it's a requirement, a bug, through an approval workflow.

And then second, each of these items maintains traceability within Ketryx. And that could be connecting the bug to a change request, so a change item that we're managing Jira, or directly into a requirement that's been documented in the source code. And we'll actually do that for our first requirement. I premade a change to our requirement around image navigation and manipulation to resolve the anomaly that we're experiencing in the product. And so what I'm gonna do here is actually connect this anomaly to the requirement that's been updated within within the project.

So let's go ahead and we will create that link. And what we'll see now that we've linked this particular anomaly directly to the requirement that lives in the source code. And if I want to see in the code repository where this requirement is documented, I can navigate to any particular system directly from my Jira environment. So if I wanna go in and look at image navigation and manipulation, I can click this ID there, and this will bring me directly into the code repository where my team has documented the acceptance criteria associated with this software. Now in the background, Ketryx will track all changes to these items.

So in the case of this bug or in the case of a requirement, what you'll see on the Ketryx side is a complete trail of all of the changes that have been made, whether or not those changes are made in Jira or whether they're made directly in your code repository. Now this allows us to do a few things. First, it gives you a very clear auditable history of changes to a particular item, but it also helps you understand the overall change across versions of your product. And for this particular example, I'll go ahead and filter down just to show the new or changed items in this patch release that we're working on for the particular anomaly in question, this MIBs. And what we'll see is we have a set of we have a software specification.

We have a software requirement and a number of new test cases to verify that that particular anomaly has been resolved. Now one of the things that is quite helpful about this structured view is it shows us exactly what documentation is going to be updating in the next version and what parts of our product are being modified. In addition, what can be helpful is to leverage the assistant to understand these changes qualitatively. So what I've done on the right side is I've opened up the Ketryx AI assistant. And as someone that might not intimately understand this particular defect, I can come in and ask a question to the assistant, which has both an understanding of all of the requirements and Jira items, but also understanding of the changes.

So I asked it, help me understand m I v sixteen, and it went through and analyzed specifically the anomaly the anomaly in the context of my product. And then it also identified change requests that were linked to that anomaly that may resolve it. In addition, I can scroll down and I can see what steps do I need to take. For example, I need to mark a particular requirement as being affected by this anomaly. Now, I previously asked whether this anomaly was affected or affected this particular requirement, but there was no requirement linked.

We just made that update together over on the Jira side, so we'll go ahead and ask the question again, and let's see what the assistant has to say. So now we can see that the assistant identified that the particular anomaly impacts this requirement that we just traced together into the source code. Now one of the things that I think is is critical as we start to think about moving more of our work closer to the source code with respect to documentation and traceability is how to catch issues around traceability earlier in the process, both from the perspective of we don't wanna fix traceability, but also from the process that we wanna make sure we're building the right thing. Alright. So we'll we'll jump in here to the the traceability module that helps us understand that global view on traceability.

So not just that local view that we saw in the Jira widget, but an understanding across our entire v where there are traceability gaps. So we've configured this to be from use cases, which live in Jira, to design inputs, outputs, and V and V that's been documented in in the source code. You know, source code front, we have text files, markdown files specifically, but we could also annotate aspects of our application with documentation. And on the verification side, we have a set of automated tests. So each of these, which we'll we'll jump into in a second, are automated test protocols that automatically get picked up by Ketryx and allow you to trace those test protocols directly to the thing that they're testing.

And then when that test runs in your build pipeline, you report the results to Ketryx, and they'll be associated directly with that test case. Now what we will see in in this particular example is that we have some traceability gaps, specifically from these two software item specifications, part of our software design, up to a design input. So we're missing some traceability, and therefore, we have these two sort of hanging elements. And as we scroll down, or even better yet, if I go ahead and filter on design inputs missing design outputs, I can see those two software requirements that are that are missing specifications. Now, this is a great visibility.

We can always come to this screen to to get an understanding of of where our traceability stands within the project, but we also wanna catch these these issues earlier. So if we are helping move some of the documentation close to the source code, we wanna catch these before a change gets pushed into our into our repo. And this is where some of the integrations that we've done into the development environment can can help us get ahead of those issues. On the right, we've now entered a cursor in this case, but this could be the same for Cloud Code, really any coding agent that you leverage in your daily workflow, the desire to ask and understand where the traceability gaps are in the documentation that we've done. So I'm on a a particular item here, which is one of those software specifications, and this particular item actually needs to be traced up to a a software requirement that we've prepared.

And on the right, what we'll see is we asked Ketryx where the traceability gaps are in our particular version. And it's given us similar information similar information that we could glean from going to the UI, but in this case, integrated directly into the place where our developers are working. And in this case, it shows that we're missing some design input coverage on two software requirements, this image navigation and manipulation, and then the DICOM image display. So what I'll do is I'll go ahead and and create the the missing traceability, which was the relationship between this software item and the software requirement around image navigation and manipulation. I can go ahead and save that.

I'll ask our friend Cursor here to go ahead and and push those changes. And when we go back into the development environment and and synchronize with Git, we'll now see that the traceability updates have been reflected into UI. So this is just, you know, a few ways to think about how to accelerate the, I guess, or prevent missing traceability gaps. And now you can see that we've now connected that other dangling specification and and covered all of our design inputs. We still have some additional work to do on this front, but at least we've closed that one gap.

So that's a bit of a deep dive into traceability, into the source code, and how we can make that process more seamless within our development environment. But ultimately, all of this wraps into a release process. And in this case, we're working on a patch release to resolve that that one anomaly. And when we come to the release dashboard within Ketryx, we can see a unified release view across our tools. So whether that is a bug that needs to be resolved and closed in Jira, or it's a requirement that's come from our source code repository that needs to be approved, we can get a unified view of all of those processes in this screen.

On the right, we have a release checklist, which will help us understand those process steps that need to be executed and enforce that we follow our our QMS. Ultimately, at the at the end of the day, we wanna go ahead and generate a set of documents. So this will go ahead and pull evidence from our various tools into our Word and Excel templates that allow us to submit for certification, for approval, etcetera. And these documents can be configured to pull in any aspect of your documentation into your preferred template. So in this case, we pulled down the software requirement specification, and what we'll see is a use case, in this case, our our play sign, our multi frame images, which has a source from Jira in addition to other requirements that come directly from our Git code repository.

Now there's a lot more that we can achieve with closer integration into Git tools, everything from tracking your code change history to managing risk objects and tracing risk controls. But I hope this is a little glimpse into how we can more effectively and efficiently interact with coding and documentation that happens in other tools on other platforms, but relates intimately to the work that's being done in a system like Jira or your requirements management tool. I think I'll close out the the demo here, but, really, I hope this helps you understand how you can better leverage evidence that's spread across platforms and leverage AI on that context to help you better understand the changes that you're making and help you make trade offs in your development process. Anything else, Yelani, that you wanted to add before we close out here? Thank you, Gabriel.

Very helpful to see that, especially the viewing to traceability gaps within the code system or GitHub. Wonderful. In that case, we'll we'll close out. Please reach out. We love talking about this this problem and finding ways to to help folks deliver lifesaving innovation to patients across the world.

So please feel free to to reach out, and thank you for the time. Thank you, everyone. Alright. Hi. Can everybody hear Hi.

It's great to see everybody. Can everybody hear me okay? Alright. Well so hi, everyone. I hope you enjoyed that Git for IEC sixty three zero four webinar.

My name is Mansa Karthik, and I'm a client operations associate here at Ketryx, which means I work very closely with our customers to help measurably improve their process performance. And my background is also in cybersecurity, so I'm very passionate about helping safer systems be delivered faster, and Ketryx helps pave the way for that. Today, I'm gonna be facilitating your questions from the q and a box to Tanishka. So, Tanishka, do you wanna introduce yourself? Yeah.

Thanks, Melissa. My name is Tanishka. I'm a solutions engineer here at Ketryx, which means I work very closely with all of our different medical device and GXP, folks in the enterprise space and navigate what process improvements we can make and how Ketryx can fit in to really streamline their documentation and release activities. So happy to demonstrate anything in the platform that you'd like to double click on or answer questions in detail with with a few walk throughs. Alright.

Great. So let's just jump right into it. I think a good question to get us started that also is very demo able is, can you speak on the generation of a DHF or a design history file? So Ketryx automatically compiles all of your controlled items into a submission ready DHF, And the data is captured continuously during development, so you can generate that in a single click as will demonstrate right now. Yeah.

Great question. So I'll go ahead and share my screen here. Give it a give it a second to load. Awesome. Can everyone see my screen okay?

Yep. Awesome. So as Maiso mentioned, what Ketryx does is interoperate with all of your tools. That might be Jira and GitHub, as Gabriel demonstrated earlier, but it may be a variety of other tools like JAMA, Polarion, Azure DevOps, Bitbucket, TestRail, and more. So Ketryx acts as that unified data layer, bringing information from all these systems into one centralized location for end to end traceability, release management, and making sure you don't have any compliance gaps across all these moving parts in your organization.

What we're looking at here is a sample project we're building. In this case, it's an insulin delivery monolithic system. This just means it's a mock project that we're building that's connected to our Jira and GitHub repository. Now when we click onto the all items page here, we can see all of our different items that are part of this release. In this case, it's a one point o one release, but we can also work on two point o, two point two, and take a look at any changes that have been made since our last release by comparing here.

Now we can take a look at all of our vulnerabilities, our dependencies, along with all of the design controls or elements that are part of our system. You'll see here that we have a few items that are read in directly from GitHub. What that means is that Ketryx allows developers to take a developer centric documentation approach, or they can simply write down the design outputs or the specs that they're working on in markdown files. Or Ketryx can even pull information directly from the functions they're writing using these annotations in the source code. So here, we'll find a few basic annotations, and that allows Ketryx to read in this document as a software item specification.

In addition to our markdown files, JavaScript, Java, and TypeScript files, we may also have automated testing that lives in our source code repository. Clicking into the source code, we can see an example Cucumber test here, again, with the simple tagging language in line three that allows us to pull that information into Ketryx. In addition to information from our source code, we also have all of these different I c sixty two three zero four compliant items that live in GitHub or, sorry, in Jira, in this case. And now we can build end to end traceability by using this trace widget and adding links to specifications that you may have written in a markdown file or an automated test that's verifying this design input. So Ketryx allows us to take all of these components across our system and build end to end traceability.

We can see exactly how our use cases trace to our design inputs, outputs, and verification testing. We can take a look at any gaps we have in approvals or if any testing is missing. We can see our results of our automated testing and take all the information that we've been working on and pull it into documentation using Kedric's very powerful templating engine. So here, we have all the different components. We can go ahead and sign off and approve them.

I'll filter for any items that are in a resolved or ready to review state, and I'll go ahead and sign off on that item. So here, you'll see that we have part eleven compliant approvals built into the system. And when I sign off on any item, Ketryx keeps an audit log of exactly what was changed, what was approved, and who approved that. So clicking into any item, whether it's Git or Jira based or any other system, we can see exactly how that item has changed over time, who's approved it, and compare diffs as well. Now clicking into this item here, we'll see that my approval has been captured, and all the approved content will then be pulled into a DHF.

I've navigated to our release management screen here where we can see the progress of our release, each of the design controls, test executions, and other components in our system. And then we can go ahead and generate these documents. Now Kedrix has a very powerful templating engine that can pull the right data fields and changes directly from your source code repository and connected tools into these templated documents. These are highly configurable, but as you can see, we have many out of the box here. And this extends to system design specifications, a code review report, traceability matrices, change reports, and more.

So I'll go ahead and download this system design specification. And I'll open it here as a PDF. And what you can see here is that we are pulling in information directly from our source code into this document. So this is one example of how Ketryx helps automate that DHF by pulling in the right information across these systems into these generated documents. Bless me.

Thank you so much, Danushka. That was awesome. I feel like you really went end to end and ends up with that DHF that we can generate. And so thank you. And I think you also touched on a couple of other questions that we have, which is about how we can ensure part eleven compliant signatures in GitHub.

And, essentially, Ketryx acts as that compliance layer. So we sit on top of the Git provider to ensure that that entire process is validated, and we enforce a quality gate. So we require electronic signatures that meet twenty one CFR part eleven requirements by capturing the intent, identity, and time stamp within the Ketryx platform. Do you wanna demo that a little bit on the platform? Yeah.

So as we showed earlier, we can take any item and embed that part eleven signature directly within that that tool you're using. So whether it be in Jira or in a tool like GitHub, we track all the changes that you're making over time. And when an item is in a ready for review state or as soon as you've pushed your GitHub commit to to the appropriate branch, Ketryx will read that in and notify the configured approval groups that their approval is pending. Now when you sign off on on a ticket using either a click through or a biometric signature, Ketryx keeps a audit trail or record of exactly who made that approval or who signed off on that approval and keeps that information stored in Kedrix. So we can enable part eleven approvals for any item or any file that's being read into Kedrix from your source code.

So, hopefully, we answered your question, Simone. And I know someone just asked a question about the DHF. This is where we have that living, breathing, real time DHF where we're pulling in the approved content into these templated, highly configurable reports. And you can always store your DHF in Ketryx and see exactly what what has changed over time. So for version one point o, we can see all the documents that were generated here, part of this DHF, and the one we're working on right now.

I see a few other questions here about the input of Word documents or or Word files. So in addition to markdown files and Jira tickets, we can also take the work you're doing in documentation and pull that into our system. Now in this case, you see an example of an SOP, but this could be any Word document that you want to upload into our system. From there, you can then do approvals around that document as well as build traceability to all the different components like testing or requirements in your system. Now we do advise folks to take their documents and break them out into items.

So rather than having one test protocol document that you're linking your design outputs to, you can really effectively do change management by seeing exactly what the execution is and rerunning only the affected verification and validation test cases when a change is made upstream. So if we change this design input, we may not want to go through a test protocol document to figure out which tests are impacted, which ones do we need to rerun, and how to update all of these documents manually. Instead, Ketryx will identify for us that these are exactly the test cases that we should look at, rerun, pull in the executions, manual or automatic, immediately, and generate the test protocol documentation as well. So whether that's a test plan or testing report, we can pull that information in immediately. So, hopefully, that answered your question, Christopher.

Please feel free to reach out to us with with any additional information as well. Awesome. Thank you. I think we can also let's let's switch gears a little bit to AI. I see a really interesting AI question in the chat.

Someone's asking, what AI provider is used in the background, and how do we ensure that the data analyzed that no data is analyzed and used to train the model? Yeah. Great question, Andrea. So Ketryx is built off of Anthropic as well as OpenAI, but the model used in the background can be changeable. We're we're provider agnostic.

So if your company uses Gemini or Copilot or if you have your own company, GBT, or model that you're using, we can have Ketryx run run on that the Ketryx AI run on that. Now great question around data privacy. We have a zero data retention policy. So none of your data is stored or used for training purposes. That's in our contracts, legally binding.

And we can ensure that none of your data will be used in in training activities. Now that being said, the AI assistant is is fine tuned to the work that's being done in this system of Kedrix. So you have all of your SOPs, your Word documents, your vulnerabilities and dependencies from your repository, your specs and design outputs, design inputs and testing activities, as well as post market activities connected from all your different tools right in one place. So that allows the Kedrix AI assistant to have the right context to operate over. Unlike a ChatGPT or Cloud that has the context of your everything on the Internet, we can really narrow that context window down to your system, your QMS, as well as your work instructions.

So the recommendations you get from our AI assistant are highly tailored to your processes, to your tools. And as you make changes, as you approve items, those items feed back into the AI assistant to provide very highly tuned responses for your company. So here, we have a few examples of how we can use the AI assistant. One I had run earlier was, can you create a report summarizing the work done in my source code repository for a quality executive? So the AI assistant, having the context of your release checklist, your release processes, as well as your source code, can go through and actually create a report for us that outlines at a executive level where are we at with our release, what needs to be changed, and where are there possible compliance gaps as well.

So we've gone through and gotten a high level summary along with really actionable recommendations. So I'll scroll down here to the recommendation section where we'll see the strengths and weaknesses and a list of immediate actions we can take, such as updating jQuery to a newer version dependency or take some other other actions as as well here. Another AI assistant prompt we can use is checking if there are testing gaps in our system. So navigating to our traceability matrix, you'll see that we have these configurable checks here, and we can easily see when there are links between items. So this design output here, insulin dose and glucose reading, is covered by this verification test.

However, that's just through a link, but not a semantic understanding of does this test really appropriately cover all of the acceptance criteria? So the Ketryx AI assistant can go through, see if there are any gaps in test coverage, and then even go through and create a pull request for us with the automated test cases it suggests. So we can go through and see a a summary of changes suggested as well as a file that we can read through with these Kurkin tests and and iterate on these and choose to merge them, if if we'd like. So those are just a few high level ways you can use our AI assistant as well as use our AI agents to really refine what you're writing. Developers don't like spending time writing paragraphs and paragraphs explaining all the work they've just done in the in the code repository.

So they can simply write up a quick draft and of of the work they've done, and our AI assistant can go through and highlight any quality gaps or compliance gaps when it comes to the writing they've done. So they can write that first draft and work along with our AI agents and AI assistant to really have strong recommendations for how to improve the wording in accordance with I c sixty two three zero four and your specific QMS. And this actually reduces the rework cycles when quality says this wasn't documented correctly or you haven't, thought through all of the acceptance criteria. Right? So having each member of your team equipped to be a quality expert and really improve their first draft helps makes quality's job much easier and helps you get to that release faster as well.

So I hope that answers your question, Andreas. And you can always email us or reach out to us to learn more about our our AI functionality. Awesome. Thank you. That was an amazing demo and really showcased the abilities of the assistant and the agents.

We have a question that's very interesting. It's basically about medical devices that combine software and hardware. So situations where the v model remains conceptually similar, but the trace matrix has to expand to include hardware components, and there needs to be, like, validation that bridges both domains from Christophe. So is that something that you'd wanna demo with, Anushka? Yeah.

That's a great question. Kedrix actually allows teams across hardware, software, embedded firmware AI to all work together in our in our platform. We can set up projects for each team. So we may have software working in this project, hardware working in this project, and we can use our system of systems functionality or setting up a microservice architecture to reference in the work that other teams are doing into a system level project. So we really want teams to be able to do their design controls, design inputs, testing activities, documentation activities separately, and have a lot of configurability when it comes to the end to end traceability and documents they need to produce as per their their processes, but then bridge that altogether when it comes to a product level release.

So here, we'll see that we have this software system where we're managing our software components. Here, we have a hardware system where we're mark where we're managing our hardware components. And we can see here that each of these subcomponents are on different versions. We have hardware working on one point two, software on one point one, and we can bring in all of the right work into our system of systems product level release. So in this traceability view, we can see tracing from high level user needs and system requirements at a product level to how these CS software component tickets trace to that product level requirement as well as how our hardware requirements trace up to the product level requirement.

So we're able to pull in the right work that's being done across these teams for a system level view and ensure that you can always have that end to end visibility. So an executive can come in and say, how close are we to releasing version two point o of our product? What are the gaps, from a software side, a hardware side, or testing side? And you can really easily visualize that in this, in this configurable trace. Awesome.

Great. Yeah. I think you really covered how we, are applicable to both SAMD and SIMD companies. So thank you. And we have another question from from Christophe, which I think is really interesting, and it's how is the integration of risk mitigations or risk controls done in Ketryx?

Yeah. Awesome question. So I want to make sure we touched on Christophe's question. We can always do a deep dive into hardware components and hardware testing. So whether it's managing hardware specifications, pulling in hardware testing items, or test evidence into Ketryx, we can always pull that information in from the tools you're you're using today.

Now when it comes to risk management, we can provide end to end risk visibility through our risk module. So you may have completed an FMEA, and now you want to write up all your risk analyses. Right? So how how does the hazard sequence of events had hazardous situation, harm, etcetera, what is it for a specific item, as well as complete your initial and residual risk analyses and build links to the risk control measures that exist in your system. So a very powerful part of Ketryx is seeing end to end management of risks.

We take a risk based approach in how we develop Ketryx and how we guide all of our customers. And what that means is for each component, we take a look at, is this introducing a risk? We can look look at the risk that's documented as well as view traceability to those risk controls. And having an item based view like Ketryx or a a digitized approach really allows teams to manage change effectively. If a requirement changes that introduces risk, we want to immediately see, is it continuing to introduce risk or is it no longer introducing risk?

Similarly, if a risk control measure changes, we want to immediately see, is it continuing to mitigate this risk, and does it need to be reverified? So we can ensure with our QMS controls or computational controls that all the changes, especially changed risk control measures, have passing test executions before you go to release. And that's just one example of how Kedrix can help enforce quality without slowing down the innovation, the changes, and iterations to make your product better. So I know I know we're at time here, but always happy to dive deeper into risk management and how we can help provide this end to end visibility of risk controls, introduce risks, testing, and more. K?

Thank you. So thank you, Taniska, Gabriel, Yulani, for showcasing the depth of your product knowledge and just the use of Ketryx. Please feel free to reach out via email or schedule a demo if this was interesting to you, and thank you for your all your questions. Have a good day. Thank you, everyone.

Thank you. Bye.