---
title: "Validating AI and LLMs in GxP Use Cases"
type: webinar-transcript
publisher: Ketryx
source: "https://fast.wistia.net/embed/iframe/ie76369au3"
content: auto-caption transcript, proper-noun corrected
---

# Validating AI and LLMs in GxP Use Cases

*Ketryx webinar — transcript of the recorded session.*

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

---

So welcome everybody to this webinar. Today's topic is, validating AI and large language models within GxP use cases. We're gonna review a lot of use cases. We're gonna give some very practical advice about what to do. We have worked now with a bunch of teams facing this challenge and thinking how can you develop and deploy this type of safety critical system, that is ever changing, that is statistical in nature?

And to us, it all starts with this diagram that you see right now on the screen where you have all these different systems, that are being made. And I know it's a little hard to see. We'll highlight this a little bit later. That purple box is kind of a specific AI use case being made in this, factory for, validation, factory for GXP, development and product making and reviewed by different teams and different stakeholders. And now we know that a lot of the sources of that information come from kind of model providers like Anthropic, OpenAI, and others.

And that's the question. How can you build these type of validated use cases, and ship them around the world? So Gabriel, maybe So before we start, we're gonna record the session. You'll get the slides at the end. Please ask questions.

We have folks waiting, to respond to questions. We'll have a feedback survey at the end, or if you exit in between, please give us your feedback. We use that to develop and improve our webinars. We have multiple webinars now every week, every month, and, all of them are available, for free on demand on our website. So you're welcome to watch historical webinar, everything from part eleven compliance to AI building.

And let's start as all good things should with a survey. So the survey is what GxP AI alignment use cases are you currently considering? Let's get started with this. So my name is Erez, founder and CEO of Ketryx. I used to be a physicist a long time ago, and then I worked at a company that makes tools for physicists.

I had a stint working at Amgen helping develop AI solutions, across the company mostly focused on combination products. Then I went to MIT where I studied computer science. My focus is actually the, limits of machine learning models during black swan events or or critical events. And then I started Ketryx as a student at MIT. Was lucky enough to find some great partners in the life science space and great folks to work with like Gabriel.

And what we do at Ketryx is, accelerating the rate of safe innovation, mostly focused on complex systems, AI software, software enabled hardware, and the utilization of those type of methods like AI within the manufacturing and development of safety critical products. Gabriel? Hi, everyone. I'm Gabriel Pasquale. I run our solutions engineering group here at Ketryx.

I started my career as an embedded system security engineer. So deep in the cybersecurity space at the MITRE Corporation, focused on all things security. I went on to work at MIT work at Amgen, following a master's and an MBA at MIT. During my time at Amgen, I was applying AI more on the manufacturing side and ran into a lot of the challenges of validating AI, for these use cases. It's through this experience at MIT and Amgen that I met Erez and joined full time.

I've been helping folks evaluate and implement our platform for a few years now. So I've seen a lot of lot of different use cases and a lot of value delivered to our partners. So looking forward to this conversation. Wonderful. And, yeah, let me introduce Ketryx.

So Ketryx is a way to develop and deploy, regulated products mostly in life science through AI driven automation. It's a combination of validated automation and AI tooling that connects to the systems you already have, like Jira, GitHub, and AWS, and allows you to automatically generate all evidence of compliance and accelerate your product delivery, connecting quality and compliance. It's used by three of the top five medical device manufacturers and many other leaders in life science, including many of the leading life science companies in the world. We're gonna talk about AI mostly and how to build AI in regulated environments. That's something I've been doing for the better better part of the last seven years of my life.

We have helped a lot of companies actually do that and ship these type of products. But then we'll have a demo. The demo will be in Ketryx, but it won't really be a demo of the product. There'll be a demo of the how do you validate a GxP system for AI. We'll talk about the common use cases.

Why is validating, AI and validating in general so difficult? How do you validate GxP AI systems? Strategies, metrics, monitoring. We'll do a case study of a partner we worked with and then a demonstration that Gabriel will lead. Please feel free to ask questions as much as you can.

We love questions. We love engagement. Love participation. Love answering questions. So let's look at a few use cases.

It was actually hard to, like, build a slide with all the use cases we've seen and we had in mind. We decided to not even include the commercial marketing, which some of them are actually kind of regulated, kind of, practices and and use cases that are very common now and really focus on the ones that have to do with touching the product or the quality of the product. So we could say everything from kind of drug discovery to using not just, information about the drugs, to using, precision oncology information like pathology slides, and we have a customer we're gonna talk about later, that uses us for this type of, solution and actually, then resells that solution to many of the top pharma companies under GxP practices. The ability to optimize clinical trials, whether that's recruitment strategies or the data transformation or the processing of the notes, or anything of that nature. Automating labs and manufacturing sites.

We've seen a lot of posts recently from folks about how, lab and manufacturing are getting automated more and more in this dream of creating the automated chemist, the automated, scientist to do work, while everybody's sleeping. A lot of use cases around change management, and how to streamline the documentation of validation and other things, assuring traceability. Post market surveillance, of course, I saw that was a pretty big topic. In our use cases, this is one of the hottest areas, of AI and has been for a long time. People have been building AI systems for post market surveillance complaint, triage management for a long time.

And, definitely, there's been a huge breakthrough in the past few years. This is the main research area for me, both as a student and as a professional in a bunch of different scenarios. And then this idea of automating documentation, not just for change management, but for regulatory submission and just in general, like the IND and DA documentation. We've seen a lot of great use cases, and we know that, that's coming. And and last kind of part of this use case question is we know that a lot of these, do need to be validated, do need to be done in a GxP environment in order to leverage them to the maximum ability, and that's what we're gonna talk about today.

And, you know, I would also start by saying, wow. What's the what's the impact of validation? Why do you wanna even talk about this as you set up this kind of, question of how, how this works, why do you need to modernize, why is it so difficult, why do you need to think about this before going to do tons of AI projects? Well, it's because validation is a major cost structure even for traditional embedded or kind of, manufacturing automation software, even worse for the cloud, even much more challenging for AI, and such systems. So if you think that traditionally it would cost thirty to forty percent of the project cost, could be even higher for AI systems, cloud based systems, that's based on my experience doing it as well.

And figuring out the validation strategy and the validation strategy at scale is the first step to understanding how, how to actually do this. And we know that people can reduce this quite substantially. We've had many customers that have reduced in the eighty, ninety percent range, some sixty percent of their total amount of time and energy spent on documentation about validation. So, there's a big, big need here for that. And what is validation?

I love this definition, that was, you know, in the two thousand two kind of GPSP general principles of soft validation guidance. Lucky enough to be working with one of the reviewers of this guidance that has quite a few ideas on it. And I just wanna read it out loud so we're all on the same page. Validation is the confirmation by examination and provision of objective evidence that software specifications conform to user needs and intended use, and that particular requirements implemented with software can be consistently fulfilled. There'll be three major ideas in order to validate a system.

One is you need to have a user need and intended use. Two is you need to have objective evidence that those are consistently fulfilled. Right? And the consistently fulfilled is that third part. You need to show that it is, it will happen, and it happens within the qualification limit or the intended uses that you have in mind.

And this idea of qualification limit is gonna become very, very critical as we discussed how to validate AI. And this is where I think I give the the room to Gabriel to take us a little bit about why validating AI systems is so difficult. Yeah. Absolutely. Yeah.

So why is validation of AI systems so difficult? And I I think it's kind of a it's a kind of funny question to pose after going through that slide where we say that thirty percent of all costs of projects go to validation. So I would say that validating AI systems is challenging to start because validation is challenging in general. Now, where does that crop up in specifically within AI? I think the challenges with AI is change management is quite frequent.

Software, a production line, those are static things, but models are changing. The data that we put into the models is changing, and therefore, change management needs to be frequent. The second component is that we're using often external models. We're leveraging things like OpenAI, Anthropic, Google. And that means that part of our supply chain, our software supply chain for the use case can be continuously updating.

And therefore, we need to have methods to to to validate that change. Another big challenge is the perception that nondeterministic outputs cannot be validated. So I think this is particularly for those that are implementing AI, communicating to leadership and those that come from a traditional validation background, that we can in fact, validate an AI system that has non deterministic non deterministic outputs. I like the analogy of, you know, a clinical trial in of itself is somewhat non nondeterministic in the way that we do validation, of our product. And then finally, I think the core challenge and one that we'll talk about a lot today is how quality and development are disconnected.

Oftentimes, development activities are done in one set of tools, as we can see on the the diagram on the right. And then quality and documentation is done in a different set of tools. And the friction that happens between, these two tools and life cycles, is what ultimately prevents and it slows the the AI validation process. Makes it challenging. But, ultimately, the charter today at companies, and and we hear this from from executive teams across the space, is how can we do more with less?

How can we leverage all of these innovations in AI to help scale our operations, maintain the same headcount, but deliver more therapies to the market? And this is the charter. And it it's funny. I mentioned, you know, doing this work back at Amgen, you know, years ago, and the idea of validating a single AI use case, being, you know, insurmountable, and moving towards an area where we have to validate ten, fifty, a hundred in order to achieve the goals we want to do, not to mention tech. And I think, Arias, you're about to jump in there.

Yeah. I I just I'm reminded of this conversation we had with one of our our great champions who actually transitioned into tech into biotech from tech. And he called us in. He's a leader in a pretty prominent company, and he called us in after, a few months on the job. And he said, you know, I found your website, and I happened to connect with him after one or two conversations.

And he said, you know, when I got here, I didn't understand. I came from a large tech company. We release tens of thousands of AI models every week. I don't understand how we would be able to do even a fraction of that here given the amount of effort around, releasing an application into production, in a validated state. So and I think this is, like, the real challenge.

How do you do this at massive scale? Not for a one off. And and luckily, it's kind of been solved by many medical device companies by now. And I think what we're we're also seeing just from the the regulatory perspective is kind of the shepherding. Hey.

Here is some guidance. We have recent guidance that came out from the FDA on the use of AI and outputs from AI model models to support regulatory decision making. We'll weave kind of this story into the the demonstration and how we we talk about validating AI. But I think the the charge here is there are, you know, there's regulatory guidance coming out. We have the opportunity to leverage AI models more and more.

And the challenge is gonna be how do we accelerate the the development of those internally, in a safe and reliable way. So with that, I think we'll move on to talking about how do you how do you validate GxP AI, and I'll give it back to Erez. Yeah. Thank you, Gabriel. So how do you validate GxPII?

I think the first part of this is you wanna do a lot of the stuff we're used to doing overall on under guidances like GAM five, right, or or standards like GAM five. Basically, we wanna take this risk based approach that everybody's talking about, the FDA knows and loves, and, the EU knows and loves, and figure out what risk of the system. There's a great question that was just asked, by an anonymous attendee that has a lot of detail about how do you do this, how do you trust. And I'd say, like, one of the key aspects of what you need to do to a vendor and contract and accept is, what kind of risk class are we in? What kind of risk class is the use case?

Is it critical for us? And so to answer that question, we go to a traditional risk assessment, not of the system being worked, but of the use case. Right? Like, is this gonna have a lot of impact on us if it works or doesn't work? What are the different, aspects of this use case?

Then we need to start talking about the system. Does the system because it uses a third party model or a model from, an open source ecosystem, is that good or bad? Does that increase the risk or reduce the risk? And then we need to start thinking about how we would be able to, basically do that validation or running through, but at a much higher throughput and much higher scale. Right?

So you have this assessment of the impact of the system. What kind of risk did they have? A lot of the risks will be top down coming from the use case. Some of the risks, which we're gonna talk about in the next few slides, are gonna come from the fact that you're using, usually a third party large language model, and it's doing this type of statistical operation. Then you need to think about the severity, the probability of the issue coming up, and assign the risk level, and then decide what kind of process you wanna follow.

And and then if you really think of what the the FDA is talking about, how do you kind of define this validation? So in the FDA's guidance, they give them this idea of the context of use, which is related to intended use. And we understand how are you gonna use this AI system for regulated decision making or regulatory decision making. And then you want to have, a risk assessment of the AI model to understand what it is that you're gonna do with it and what are the risks that the AI model comes with. Unlike, simple, deterministic manufacturing software that's built in house that is run on a on come some kind of microcontroller, there's a lot of risks coming from the fact that you're using a large language model that can respond in a variety of ways that, comes from a third party that is updated very frequently.

All those introduce a bunch of different risks that are more unique to AI. And then from this kind of risk assessment and context of use comes the user requirements and functional specification. What is this trying to do? Right? And then that all comes into this idea of the credibility assessment plan.

Do we think the machine learning, the product we're using is credible? How do we assess that credibility? How do we score it? How do we know if it's working or not working? And then we wanna execute this plan.

Basically, test this thing, make sure that the product, the model is as credible as we want it to be, validated to that credibility score. And then do we think that it's adequate to perform this context of use? And if it is, well, let's deploy it and monitor that. And then if no, how do you go back, redefine your context of use to make sure that it is adequate? Right?

So there's this question of, is the use case appropriate to be used, by, to be executed by a statistical model? Can you even validate that? And is this specific model good enough for that use case? Right? And that's gonna come up a lot, this idea of the metric.

Every use case, this is you know, if there's one thing people can take from this entire webinar, and we'll repeat it a few times, is this idea of the metric of the use case, the metric of what you're trying, to do. And that's gonna change between every use case. It's actually not that dependent on the model. It's much more related to the use case. Am I forecasting or classifying or generating documents?

All of those have different metrics, and companies will need to find experts to help them define that and then help scale that library up. And so what does it look like to do change management to this AI system? Right? So let's say we did all this. Right?

We've done everything described on the previous slide and on the earlier slides that Gabriel showed, which we're gonna dive a little bit more into in a few slides. What happens then? So I have then a validated model that have has gone through this credibility plan. But now I need to either use a new model and either fine tune it. I retrain it locally or retrain a complete model.

In most cases today, people mostly fine tune. Sometimes they don't even do that because the models work really well, because they've already seen a lot of the data you're gonna fine tune on. But, basically, the idea is you take that model, you retrain it. Maybe that's even something that you don't do, but anthropic does for you. Right?

Far away. And then they send you this new model or you retrain this new model. Again, some biotech use cases would require very specific models. And then there's this question of the acceptance criteria and impact assessment. Is the new model good enough?

Does it pass this criteria or metric that you're trying to measure its success on? Is it qualified within the qualification limits of your criteria? And what's an impact of this change? And then you need to think, is that impact big? How much documentation do I need to generate?

And then you need to both document everything we just talked about and release. So what's really interesting here is if you look at the bottom right, there's this five step process where I get new data, I need to check the quality of the data, segregate the data. I then need to, get the model, retrain it, reinsert it into my validated infrastructure, and revalidate the whole thing. So now if I wanna do that for a hundred models a week or even ten models a week, I start realizing that I wanna separate my models from the infrastructure that serves them, and then be able to validate things separately and deploy them separately, which is really, really critical. And that's been done, in MedTech for quite a while now.

And now this kind of leads to discussion. Now we understand kind of the path the regulator wants to see and and we're used to taking. There's some new terms in these new guidances, but nothing is really kind of earth shattering. It's it's the same old validation strategies, just in a much more complex, fast moving system. We now saw that the change management is very challenging because it's gonna be done very, very fast on the frequency of a week or a month, or kind of at longest a quarter, but I expect it to actually go way down from that.

And now the question is, what kind of strategies should I take to validate my model? What are the risk based validation strategies that actually work? So one is there's these metrics. We need to decide on metrics. And whenever I'm faced with a new project that I'm doing with with or supporting for a partner or or brought in to, like, advise on this, I always wanna ask, okay.

This is all great. What are the metrics we're trying to measure for this particular use case? Because everything will be much easier than that. Once you decide on the metrics, the infrastructure itself, you know, there's companies that do that. But that's the hardest point is how do we all agree as quality professionals, as subject matter experts, as operators who are gonna use this, if that's the right metrics for us?

Then we need to talk about, reusing, reasonable validation components. You wanna have a stack across your entire IT system that allows you to reuse things that have been previously validated so you don't need to redo so much of the paperwork. Number three is all the documentation needs to be done automatically. A hundred percent of it. There's no real other option for the speed in which some companies are gonna start releasing these models and for the ability, to update them.

And then the last part is how do you monitor this and make sure that you're tracking and, basically, ensuring things are safe and reliable. And if we look at the left hand side, we see these selected risks, metrics, and monitoring strategies. So on the left hand side, we see the risks, big column. I recommend anyone take a screenshot of this. We'll send you the slides afterwards.

There's a lot of different data sources that you can take this from, from really nice online resources to, there's a standard I was part of writing called ISO three TIR three four nine seven one. It's a technical report about how do you kind of assess risk for, medical devices that are driven by AI. There's a lot of other great resources of that. So the first thing you need to think about is what's the risk of this particular use case and this particular model? The risk of the use case is usually things we're more used to that we've seen in the past before, because they're tied again to this very, usually more traditional use case that we've done before or someone is manually doing in our company that we now wanna automate.

But there are a lot of risks that are unique to data driven software or AI software, whether that's, the issue that the data has biases or is incorrect, whether that's kind of that the we trust the model too much, the model is overfitted, all kinds of issues like that. Then we need to agree on the metrics for this particular, model by different, different use cases. Different models will have different metrics. Ideally, the metric is tied to the use case. And so, for example, if you have a classification task, a very classical one is either accuracy or f one score, but there are many more modern metrics than just an f one score.

People have have developed quite far ideas around this. In fact, there's probably hundreds of metrics for every task you can think about because there's been so much research to that. And the the challenge is to find the right metric that is appropriate for your intended use and, the level of, kind of, the the error bars you're looking for. You then need to decide agree on a monitoring strategy. How are you gonna monitor this?

How are you gonna track and make sure things are okay? What we're gonna talk about and it is my belief because I think it's it's, both acceptable by regulators and companies know how to do it, and it it works as using statistical process control, across different metrics and different error spaces and different drift measurements of the model and the data to then check that everything is okay. And let's now compile all of that into this use case on the right. So if we look at this use case for AI driven complaint management, which Gabriel in just a few minutes is gonna show us a live demo of how to build that and how to validate an agent for that, including all the infrastructure, we see that there's kind of these four parts on this kind of use case score card. Right, or use case label.

There's description of the use case. There's a set of potential risks. We're just giving one example to make it easy. Right? The model could have a bias and and lead to inconsistent handling of certain complaint types.

So this model is all about the triaging and categorization of complaints, severe adverse event, adverse event, product feedback, or other. What if all the data is trained on people in Cambridge, Massachusetts? And when you actually deploy the asset, the drug, you have people who are all over the world using it, but your triage system can't really understand whether that's their language or some syntax, some information that maybe a human can't even understand is, would be inconsistent or biased, but the computer finds that. The second part is this relevant metric. What's the right metric for this use case?

It's a triage use case, so it's a classification task. It's either bananas or oranges, apples or oranges. And I need to decide. It could be recall. It could be precision.

I think those are the metrics we, have. But as part of your validation process, I'd recommend trying different metrics and see the ones that work best for this particular use case with your particular data. And the last part is how do you monitor this and ensure through SPC that things, are correctly running. So now looking at this reusable validation components, I love this pyramid chart because it explains how complicated what we're doing is. At the top of the pyramid, there's the actual use case, the validated use case that you're gonna deploy to your internal stakeholders or customers or whatnot or patients.

At the bottom, there's the infrastructure running on, whether that's local or or on prem or or kind of on prem cloud, private cloud, public cloud, whatever it is, but there is some infrastructure running on. And then from that infrastructure layer, we need to validate the infrastructure that widely depends on your use case. I think that I would, and and most teams should take a very serious risk based approach here because a lot of the things that we could validate in a cloud, for example, it's it's kind of endless. But most of them won't necessarily matter for many use cases. And then there's the specific application we're configuring, kind of the versions of everything, the structure of it, the parameters of that application.

And then there's the supply chain. Now for most LLMs, we're actually grabbing, open source models that exist in in companies like Anthropic or OpenAI or Google. And we're leveraging them within our application, maybe with some fine tuning. But there's this huge software supply chain, which is a big problem. That's why the FDA came out with a patch act and is asking to see all these s bombs.

But you'll have quite a big supply chain for this. And then at the top of that, there's the validated application that you sit on. It is really critical that when you're thinking, especially in a large company to develop this, you agree on a strategy to validate not just this particular application, but the entire pyramid all the way down, and then an ability to replace the top of the pyramid or the two top layers with different applications and run the whole validation automatically on top of this kind of preexisting validated infrastructure. This is the idea of component reuse or system of systems, and we need to figure out how to reuse all these components over time, as well as automate all the generation of the validation documentation. Because something that'll happen quite often is the model is updated, the last model used is no longer available.

It could take you five to ten minutes to replace the model. But if you need to do all the validation by hand, that could take you months and months and months of time. But if you had it all automatic, same day, same week, you could already replace it. Send people reports to review if you passed all the tests, and then kind of move forward. And I think that this ability to do a validation strategy that is lean and robust and fast and automated is the core problem all pharmaceutical companies that do GxP AI will run into.

The use case will be much simpler to identify and deploy to. And here's where we wanna talk for a second about monitoring, where there's a lot of ways you can monitor an AI system. It's not like there's, an agreed upon path, but this is the one that I've spent most of my time into because it is so well known as a general methodology for control of processes. And so what you need to do is use statistical process control chart, assume that there's a normal distribution for the metric, right, the specific metric you're trying to to measure. For example, the mean absolute error, per batch of some measurement, the pH or whatnot.

And then you need to set make sure the process is under control. And we know that a process under control means that ninety nine point seven percent of all the the the kind of data outputs are within three standard deviations of the center, of the mean of the distribution. And then you need to monitor it like mean we monitor many other things. Now it could be the Nelson rules, which are used in a lot of SBCs are not the right set of rules, but that'll come with time to figure out what's the right kind of anomaly detection method for you. And you can even run just an anomaly detector on top of this.

But what you need to see if there's any trends or if there's any out of control responses, And I could tell you from work I did at MIT that you will see kind of the, error, which is this is what we're tracking here, the error of the model, kind of respond much faster to issues than, accuracy, for a number of reasons. But this is very, very critical. How do you now measure it over time and make sure that things are safe? And so now before we get into the case study and demo, we just wanted to ask, what of these areas we talked about are critical to your AI validation strategy? And where do you see the challenge?

I just wanna share one case study we did this year with a client, one of our partners who did some amazing work, and they're developing this very complex GxP AI platform. Can't share too much about it, but basically, we were able to substantially reduce the amount of documentation required by about eighty percent to do this type of work. They're able to release much much faster. Some part of Azar is released on a weekly basis even today, some of them daily. And then, when when we started working together, one of the problems is their AI systems were moving so fast, and they had so many sites, so many different, worlds they're working in that they just could not keep up with the amount of documentation and compliance they needed to do for all these global releases.

And it created huge bottlenecks. Like, the most of the time that it was stuck in the release was because they were compliant compiling the validation documentation manually. And our solution, this ability to automatically, validate everything, generate all the documents, use AI to do that, and accelerate even faster in different type of agents we have. And then there was quite substantial reduction to that. But at the end of the day, what they're able to do is just deploy more, with kind of a similar amount of people, which I think is is pretty exciting.

And that's really, really hard to do in this industry of how do you actually do this work, especially as you scale up the number of apps. Because what I'm hearing from friends and colleagues and partners I have in the industry is all the executives are saying, you know, I wanna do I don't need to do a hundred thousand AI models like Amazon a week or a month, but let's do a thousand. You know, some very small fraction of that. And I think that's a hard realization to realize that a thousand validating a thousand applications a week or a month, could be quite constraining in the amount of of, time it would take to do that. We'll get started with this agent validation deep dive.

Let's do it. Take it away. So we just talked about wanting to achieve, you know, tens or or hundreds of use cases. So the question is, how do we achieve that? So as a part of this demonstration, we're gonna go through some of these strategies.

And one of the the core strategies, which Erez mentioned, is around enabling modular validation. So here on the screen, you can see the project structure of the projects that we'll investigate during the demonstration. And you'll see, three layers. We have our use case layer. We have two applications that are gonna be in the environment case insights and then complaint processing.

And these use cases are leveraging or are configured version of an underlying GxP platform. So things like, validating a fine tuned version of a model can live at the platform layer. And then that model and the platform can be configured for a particular use case and validated independently. That configuration validated independently. So let's go into the environment and get this demonstration started.

So here we are in the Ketryx platform, and you can see those three projects that we were just looking at or three entities, case insights, complaint processing, and g the GxP AI platform. The first thing or first a few things that you'll see is that each of these projects are being versioned independently. So we have this underlying AI platform. It's at version one point two. And then we're validating or or incrementally improving these two use cases, that's built on top of the platform.

Within each of these projects, we're maintaining all of the requirements, functional specifications, design specifications, validation activities, all of the necessary documentation for both the use case and the underlying platform. What this, kind of system of system subsystem approach allows us to do is validate the underlying platform and then reuse that evidence in the top project. And that we could become very clear as we get in and talk about traceability within this particular complaint processing project. Each of these projects is connected to a set of systems. In this case, we've connected this project to Jira along with a code repository that lives over in GitHub.

And I know we've been talking a lot about validating AI, but we will also be using AI to accelerate our our process here. So we're kind of mid flight. We're working on the minor version one point one, and we're building off of version one point o one of this particular use case. And so the first thing that I can do within here is just get a sense of what are the changes that are going into this next version. So I'm gonna ask our assistant on the right side to show me the changed or removed items.

This will allow me to filter down and quickly see that we are resolving an anomaly that's resulting in a requirement change. It looks like we've updated a risk, and we've updated a test case. Now the first thing that this brings to mind for me is we're making a requirement change. And one of the core challenges that you'll have is you're gonna be managing many, many requirements across your use case. And one of the challenges that come up when we're managing lots of requirements is requirement conflicts.

Now one of the ways in which we can accelerate our work using the Ketryx platform is through a set of agents that are running in the background that help us with our validation work. If I open up this agents module and we go over to it, we'll segue into, looking at one of these agents that ran in the background the previous night and has a few findings for us. Going into this requirements agent and into the results, we'll see something interesting that it identified the previous night. So this agent ran, was analyzing all of our requirements, and then it identified one of our requirements that includes our our metric on recall. And I identified that the metric might not be right based upon one of the requirements that we wrote.

In this case, it's configure it's concerned that we haven't necessarily, let's see. Let's pull out the exact sentence here. Based upon kind of our goal to minimize misclassifications, we haven't necessarily defined our metric just right. And so what the AI agent has offered to us is a way to update our requirement such that the metric we've selected aligns with our requirement for minimizing misclassifications. Of course, it's not gonna make any changes to our to our requirements without human review and approval.

But once again, once we go ahead and review and approve the changes, it'll push those changes out to our requirements management system where the rest of the team, the systems engineers, the quality engineers are working. Alright. So now that we've made that change and update our requirement, we can come back to the the original thread that we were on. The next question I have now that we understand what items are changing across diversion is why can't you just maybe tell me a little bit about the anomaly that's being resolved in this version? So it's not just doing a structured query.

It's going in and and giving us a little bit of background on on, hey. What are we changing across this version? As that's working, I'll I'll write in my next prompt, which is how are we going about resolving this anomaly? So here we go. It gave us a summary of what we're changing across this particular version.

Next question I might have is, how is the anomaly being resolved? It'll go ahead and process and under help me understand how we're going about this change management process on a highly complex AI use case. The final question I have before we move on and and talk a little bit about kind of connection to an external system like Jira, is and, actually, because we're gonna go to Jira, I'll open up this anomaly in Jira. The final question I have is okay. So we're going through and resolving this anomaly, updating a metric, updating maybe how we're testing that metric.

So, ultimately, the final question I have is show me the test testing oh, typo there. Show me the test testing requirements affected by this anomaly by this anomaly. And what this allow me to do is quickly understand the tests and the change tests that we've implemented in order to show resolution of this anomaly in our next release. We'll give it a moment to think, and now it will filter down and show me those tests that relate to the anomaly that we're resolving. Let's go over to Jira and approve this this anomaly, and then we'll talk a little bit about the Git integration.

Going over to Jira, you know, as a as a reminder here, we wanna enable you to use your existing tools, stay in your preferred tools, and only come to Ketryx for the specific activity level items, traceability, leveraging agents, the assistant, etcetera. For those that are familiar with Jira, we'll see that we've updated Jira in two different ways. The first is that Ketryx has inserted this traceability widget, which helps us understand the relationship between a bug that we're tracking in Jira and maybe a requirement that we're managing in our external requirements management solution. And then second, we have approvals. So wherever possible, we wanna enable teams to spend more time in their preferred developer tools, even going so as far as doing peer reviews and approvals directly in Jira.

Let's go ahead and approve this this anomaly, as being resolved, and this will allow us to go through the release when we when we get to it. Going back up to the all all items screen here, the other integration that we're leveraging here is an integration into Git. So we talked a little bit where there was a question about traceability of AI models and audit trails. And by integrating directly into the the systems where your models are maintained, where automated testing is maintained, we can get better and more granular traceability into where those activities occur. So I clicked that link.

It brought me directly to the Git repository where I've defined a lot of the metrics that I'll be testing for my particular model. And we can also trace directly into where the model itself is defined. Now instead of, showing you that on the all item screen, we'll go into the traceability matrix, which will give us a better view of the traceability across the system. Going into the traceability view, and I'll just minimize this side so we can see the full matrix. We can see a full end to end trace matrix from our user requirement specification all the way down through testing.

Now what's important to note on this traceability view that we're looking at is it's not just about the the use cases or the the use case or user requirements specifications that we're validating for this particular complaint processing use case, but also the underlying documentation for the platform and the model within the platform that we're leveraging. So the columns in the center here from design specific, design specifications, subsystem specifications through their testing is actually being leveraged from that separate platform project. This means that we don't need to redocument how we fine tune the specific internal model at our at our organization, for use across many different use cases. Ultimately, you'll also see that we have a significant amount of automated testing. So for any of that testing that you're doing at the model level, the use case level, the statistic was, oh, now we're testing my my memory here.

Eighty percent of all validation testing can be automated. So finding ways to integrate into where the automated testing is being done and automatically pulling it into documentation is is really critical here. Now the final thing that we'll do is to go into our risk management. And I think this part is is critical particularly from a scalability perspective. There are gonna be risks that merge at the use case level from a top down analysis.

They're also gonna be risk that risks that emerge through an analysis of the requirements maybe from a bottom up perspective. The way that we manage the documentation around those risks can be slightly different, enabling us to scale our, development better. The first for the bottom up use cases, for example, this model hallucination hallucinations leading to inaccurate or harmful insights might be a risk that's inherent to the platform or to the underlying model. And we may want to both document and control that risk at the platform level. The three other risks that we've identified here are risks that emerge from the use case.

So these are gonna be maintained at the complaint processing project level and either controlled at that the complaint processing project level or by controls that exist at the platform level. So if we scroll over in the risk table here, we'll see a set of test cases that are acting as risk controls that actually live within the platform. This allows us to reuse those risk control measures across many use cases that can benefit from them. Finally, this brings us up to the, release process. So normally, we would go through kind of a full verification and validation run.

All of our testing is automated for this project, and it's already run through. So if we go into the releases area and then to version one point one, we'll see a full summary of the items that we need in order to get this use case project to release. We'll actually see that there's two uncontrolled items. Yeah. And I think, Gabriel, maybe it's it's fun to mention here.

Right? We're talking about two thirty one items. A lot of people have ten thousand requirements in a project. Right? Like, some some of these projects are just so complex.

They use AI, within, you know, pharmaceutical or medical device domain. There's so many systems you need to interconnect with. Many of the products that people end up having are multi stakeholder in nature, so there's a lot of different interfaces. It's it's surprising sometimes how complex, the simplest medical devices or pharmaceutical kind of equipment that has AI or software is. That's a great point, Erez.

And I think I think we we go through and talk about how we use AI for our own kind of internal development of the platform where we we have thousands of requirements. And, you know, sometimes the demo project can't fully describe that. Right? We only have thirty one one requirements here. But this is where the assistant and having agents that do work for you in the background become so critical in order to accelerate the the development process.

And, what we what what I just did here was open up the two uncontrolled items because we're actually gonna go through a release process here in the last few minutes. When I clicked, that button here, it brought me to the all item screen, and this will show me that there's two requirements that are missing approval. I'll go ahead and do my approval here, use my fingerprint to make the approval. And then once we've approved these two items, all we'll need to do is go back to the release screen, and we'll regenerate our documents. So we haven't even talked about kind of Word and Excel documents yet.

That's when we get to the end. We click generate documents. This will go ahead and pull all of the latest evidence from the various platforms that your teams are working across. You can actually just open up one of these documents to see what that looks like. And this document here, can be configured to your organizational template.

So the margins and the look and look and feel and style will all be as expected. And then it's pulled in our requirements, testing information from from all the different systems that our teams are working across. Finally, at the release level, we can go ahead and approve our release with one final signature here. And that gives you kind of a a sense of the the full scale. How do we go from understanding the change that's going on in our particular, use case project, our validation project, through completing the documentation of all that evidence in coordinating the release.

Love it. We'll sit here to take some questions.