---
title: "From AI Curious to AI Native - Top Use Cases for AI Across Regulated SDLCs"
type: webinar-transcript
publisher: Ketryx
source: "https://fast.wistia.net/embed/iframe/3xou4yafzz"
content: auto-caption transcript, proper-noun corrected
---

# From AI Curious to AI Native - Top Use Cases for AI Across Regulated SDLCs

*Ketryx webinar — transcript of the recorded session.*

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

---

really, really excited to kick off today's session, focused on AI across regulated SDLC. So whether you're just getting started or or looking to go deeper, I think this session will have some useful, takeaways for you. Just as a quick intro, my name is Tim Broder. I'm the VP of delivery and success here at Ketryx, and I work closely with r and d and QA teams, navigating the complexity of building compliance software products at at pace. So just a quick intro on my side.

I'm also gonna be joined here, by Bailey Kanter, who's our leader of, solutions engineering at on the Ketryx team. So let's let's roll into it. We're about two minutes past the hour, so we'll get started. Awesome, Bailey. So, yeah, just some quick housekeeping.

So first off, we will record the session and have the slides available. So no need to take screenshots or or worry about missing anything. We have you on on that front. There's also a q and a, section. So you'll see that as part of the webinar platform, you have the ability to submit questions.

We can answer those asynchronously. Also, we'll we'll tee up some questions live, at the conclusion of of the demonstration. And then finally, we have a feedback survey. So, this is really important to us. If you wouldn't mind at the end of the session, share your feedback about, about the webinar.

This helps us get better and shape future content, and and webinars. Amazing. So just quickly for folks that are kinda newer to Ketryx, would love to introduce it for you. So Ketryx is an AI native compliance platform. It's purpose built for regulated teams to deliver safer products at pace.

So we interoperate your tooling across various teams throughout your organization and apply your quality rules that each team's critical tool set needs, right, to be compliant within that that process. So we can take that data and then automatically generate compliance evidence, documentation, and have that making you stay audit ready. Right? So then then you layer in the AI, and you can automatically trace requirements, assess change impacts, and validate test coverage, also flying, you know, flagging that compliance risk, in real time. So for quality teams, this actually means less manual chasing of evidence and more confidence in your audit and submission readiness.

From that r and d perspective, you know, that time spent, is more in those developer native tools versus doing manual documentation. And then for our system engineers that might be joining us, and thinking about, you know, that important role in the ecosystem, it's in instead of reconstructing intent after the fact, you can actually, you know, sort of understand change impact while you're going, as it evolves. So, you know, excited to have Bailey jump into the platform later in the session so you can see Ketryx live as well. So, just a bit about bit about us, you know, the folks that are speaking today. So as I've mentioned at the top, Tim Broder.

This is a little bit about my career journey. I'll be try to be really brief here, with a couple of these stops. But, you know, I was very fortunate to be in the early stages of the Vault r and d, practice at Viva Systems and, you know, led professional services and, customer success. Then also, you know, went upstream into a company called Benchling, led customer success there, and then also worked on a validated cloud offering for GXP customers. And then AI boomed, and then, you know, really had a, you know, fortunate opportunity to work with large biopharma customers doing, biomedical research, you know, exploration with AI at Causely.

And now, you know, really super excited to have joined the Ketryx team. Been here about eight months and, leading up our delivery and success team to help regulated product development teams, leverage AI. So that's just a little bit about me. Bailey, let me pass it over to you. Yeah.

Thanks, Tim. Hi, everyone. It's very nice to meet you. I'm Bailey Cantor. I am the director of the solutions team here at Ketryx.

Like I mentioned earlier, I used to work as the systems engineer at Raytheon in the defense space, And that is really where I saw this bottleneck of working in a regulated industry, producing software at speed, but still bottlenecked with some of the compliance regulatory efforts. Then I was a scrum master and back end software developer at Amwell, where I got to see that speed come to play in a nonregulated industry. And I'm very excited to be at Ketryx now helping teams in both the software developer role and the systems engineering role learn how we can help them, you know, create software at the speed of unregulated software without losing quality. So I'm really excited to walk you all through the platform today and dive deeper into automation and AI. Excellent.

Thanks so much, Bailey. Great. So let's, like, set the stage here term terms of why this conversation sort of matters right now. So product complexity is obviously growing quickly. Really great statistic here.

You have that FDA authorized AI enabled medical devices has increased by two hundred and forty one times over the past decade. So, for example, the FDA actually cleared six AI ML devices only in twenty fifteen. Right? But in twenty twenty five, it was two hundred ninety five. So this is not a gradual shift.

Right? It's a step change in what teams are being asked to build and actually validate. This is the shift we're seeing across all regulated teams regardless of industry. Right? So from the developer side, developers are already moving.

You know, the stats we have here, we have some of the sources here from GitHub. Right? Ninety two percent of US based developers are using AI assisted coding tools. So this isn't just some future state. Right?

Your teams right now are effectively using AI in their process. So the question isn't whether AI is entering the STLC because it already has. Right? But the question is more around, can we control it? Can we trace it?

Can we make it compliant? So, you know, we're always we're seeing this show up at the org level as well. So you kinda see this stat here. Eighty five percent of health care organizations have moved from AI experimentation to actual deployment, in the last year alone. So, you know, these are just ways to kinda set the stage, look at how the industry and and, you know, even regulators are are are grappling with this.

We wanna hear from you. So we actually do have a quick pulse check, a quick poll we'd like to put out to the audience here. So go ahead and answer the poll. How would you characterize your team's, AI maturity today? K?

So we have different options. We're using sort of a a v one maturity model, here. So we'll go more into our our AI maturity model in a bit. So, you know, is this are you at the baseline? Are you in a crawl state?

Are you in a walk state? Right? Are you running with AI and how that's, you know, working in your process and your product? Or are you flying? So we'll we'll give we'll give folks a minute here to, answer the poll.

And and, Tim, while folks are answering the poll, you know, what do you think has been the biggest blocker for teams trying to evaluate their AI maturity and getting from a crawl to a run? What has been the biggest blocker in that adoption? Yeah. I I think maybe it's just two things that I've seen. I think there's just this stall out in terms of, just not getting started fast enough.

And so, basically, just getting started. So start to use the cloud. Start to use these tools. You have to get started somewhere. Right?

Everything everything needs to get started. The second part, though, is ownership, and we'll get a little bit into this. It said, who sort of owns the AI objectives in the organization? I think when that slips and there's no real clear ownership, from a people perspective, I think that's where things start to, you know, phase out. So I think when you when we get started and we have ownership, it seems high level, but those are those are been pretty powerful in the the adoption cycles that I've seen.

So but we'll get we'll get more into it, as well. Yeah. Getting started is the hardest part, and that's not even in just AI. I think you can apply that to to many different areas. But, hopefully, we'll give some teams, some ideas today on how to get started.

And for those who are running, I'd love to talk to you more. You know? How how are you running? What are you seeing work in the industry? Maybe something interesting to talk about in the chat.

Absolutely. So thank you so much for the responses coming in. Let's see here. Great. We have some results.

So we have twenty percent at baseline. We have about sixty percent at crawl. And I I and I think, you know, just looking at some of these responses, ten percent at walk, five percent at run. You know, this is actually this data is very representative of what we're seeing. Right?

We're kind of moving away from the baseline and seeing the majority of folks in that crawl state. And we'll get a little bit more detail into how we think about these these categories from an AI maturity perspective coming up, but really appreciate the participation on this. And at the end of, of the, the session, we'll actually have a link to a a self assessment that you can actually take fully, with our AI maturity model. Awesome. So let's let's dive in.

You know, from a from a topics perspective today, we'll start with the challenges. So why AI adoption in regulated environments is harder than it looks both in the product itself and also in your workflows. So from there, we'll talk about human oversight because AI takes on, more work. Right? How do you structure process around that to have people reviewing and approving things and how that is a critical part of it?

Also, this concept of the AI native regulated SDLC. What does that look like in practice? And then finally, you know, saving the best for last, Bailey will will dive into top use cases and then actually demo, some of those use cases in in Ketryx. So, you know, just breaking this apart, you know, AI adoption is a very high level, concept. But if we think about it on two axes, it kinda we start to break down how AI is now, you know, integrating into our into our work.

Right? So the first is, you know, we start with AI inside development workflows. So this is the copilot that suggests code. Right? The agent that generates test cases.

The LLM that drafts requirements. Right? So it's basically helping you with your work. It's that sort of copilot that, you know, that co engineer with you, you know, along the workflow. But then there's also AI in the product itself.

Right? So, you know, from a medical device perspective, it could be diagnostic model that's retrained on new patient data from last quarter, a classifier that ships with your device that's changing after the FDA clears it. Right? So these are not as separate, you know, as you think. Right?

So they're they're, you know, they're they're you know, the systems used to hold still long enough so we can engineer them, but now we're kind of moving both in the same direction. So not only have AI in our workflows, we also have AI in our products, and we have to sort of reconcile those things, you know, because things are moving moving faster, right, with both of these in place. And it really comes down to, as we talk about, right, this the framing around the SDLC. You know, over the last years, we've seen regulated teams trying to move to the CICD model. Right?

So continuous integration, continuous delivery. The idea is straightforward. Right? You commit changes frequently. You merge branches.

You run automated tests. You ship on a cadence rather than waiting for a milestone. And that's how modern software teams move fast, you know, the CICD model. But that's easier said than done and regulated. Right?

So in a regulated environment, that's very hard. Every change could potentially trigger documentation requirements, design controls, traceability, risk assessments. These don't naturally fit into a pipeline that's constantly moving. Right? So we're trying to reconcile a development process that's built for speed with a compliance framework that we need to be predictable.

And this is where teams have been wrestling with this tension for years. Now you let's layer AI on top of that. Right? So with AI in your workflow, that means changes are being generated faster than ever. You are generating more code, more commits.

There's more velocity. The pipeline, the compliance the compliance team is trying to keep up with is continuing to to mount, right, with with lots of, you know, with AI just generating tremendous amount of data there. And then the the idea is the result is the system that you're trying to engineer is never really holding still. Right? CICD has already been pushing the limits of this of what the regulated space can absorb, and AI is accelerating that sort of simultaneously.

So if the system is never holding still, then what mechanisms can we put in place to sort of, you know, move at pace but also stay stay compliant? That's the question. Right? And and we're actually seeing, you know, some of the results of this work, you know, happening and manifesting in different ways. This is one way that's manifested.

And, you know, just to kind of share here, right, that folks have might be aware, but the, the FDA actually issued a warning letter to a pharmaceutical company. Right? So they found that, AI was being used to generate documents, but there wasn't adequate review of what the AI produced. Right? And the message was pretty direct.

If you're using AI as an aid in document creation, you are responsible for what it outputs, and failure to verify that is a regulatory violation. Really pretty much full stop there. So this takeaway, though, isn't that, hey. We shouldn't use AI. The takeaway more is that human oversight isn't just a checkbox.

Right? It's really kinda thinking about, you know, AI moves fast and it generates a lot, but we need someone with the right expertise, that can still be in the loop reviewing, approving, taking responsibility for what actually ships. So, you know, thinking about that, the concept can, you know, generally make sense, but there's also, a model that we've been thinking about that our teams can do to actually get this right. Right? So, you know, this is this is this is kind of the classic idea of transformations and change management.

So we talk about getting the risks that like, the risks of AI are real. Right? And they made it clear, but what does it look like to get it right? And, you know, our view is that successful AI transformation in a regulated environment requires three things. It's it's the kind of that classic change management.

Right? People, process, and technology. So this is what I was talking about a little bit before, Bailey, you know, when you when you mentioned how things stall out. It's really about ownership and focus. Right?

So it kinda starts with people. So the challenge we we kinda see with AI adoption in an organization is that the organization is already heads down on the core business. Right? You're building products. You're managing submissions.

You're trying to stay compliant. And then your AI initiatives kinda get deprioritized. They stall out. They never kind of hit the ground without dedicated ownership. So we have this concept of the pod.

Love the pod model in lots of different contexts. But in the context of AI adoption, it's super it's super impactful because you can create a small cross functional pod that has the relevant expertise across your product. You have subject matter experts potentially from the business, QARA, and some executive sponsorship that is really aligning to some outcomes that you wanna see from the AI initiative. And we'll get into some of the use cases. There's tons of use cases, obviously, for AI, but that that's one thing that you can start.

Start at the use case level, really try to integrate that into the process, and have people that really own those outcomes. So that's one thing. Right? But then that actually then transitions into the process side of things. You know, the challenge is that AI is generating outputs.

Yeah. As we were saying, there's the teams end up with faster documentation creation. Right? But there's no guarantee that those outputs actually align with quality standards. So our recommendation is to pair the generative task agents with deterministic process agents.

So one that does the work and the other that enforces the quality system. So that's how we can, you know, get to speed without creating this compliance risk. Right? And then on top of that, obviously, we need the technology, to sort of deliver on this, you know, as as that that backbone. And the challenge is that most off the shelf AI solutions, they treat human review as optional or sort of just bolted on.

But in the regulated space, right, that's really not acceptable. Your solution has to have that human in the loop. Right? So when we start from the prompt to the analysis to the recommendations, you know, from the human review and the sync, there's a subject matter expert that accepts, edits, or rejects, you know, that output and writes back, right, to the process. So it's not that checkbox.

It's really the architecture that you set up there. So all these things work together. You have that pod in place, start to orchestrate that process, and then, you know, have the technology, you know, working. So the natural question is, you know, great. You know, all of this kind of makes sense.

How do I now look at where where my team is? Right? You know, it's easy to kind of put this on a slide and say these things work, but you have to kind of go for where you are as an organization. Right? These frameworks have to apply to your current context.

And this is one thing that's near and dear to my heart, our maturity models. And I just love maturity models because it's all it's all about where am I today and where do I wanna go. Right? And, if we if I advance here, I'll just kinda share our the v one of our AI maturity model. Calling it v one because just like anything, everything's moving fast.

This is something that we've, you know, see as a great way to sort of self assess where our customers are, right, and then get on a pathway to sort of introduce AI adoption the right way for our customers. Right? So if I just build this out, you can see we have these different aspects of the maturity model based on those different stages, right, from baseline all the way to fly. So you can see from a system architecture perspective move from monolithic to microservices with continuous governance. It's more modular.

Right? You have this ability to independently deploy with compliance built in. You also have DevOps and CICD. Right? So you move from an ad hoc manual build to a fully automated pipeline with compliance rules that are forced continuously.

Right? Then there's the documentation in QMS. So we move from manually assembled technical files and documentation generation to the sort of, you know, validated you know, this validated automation that happens in real time. And then, you know, product development is is this moving from this waterfall model to continuous incremental delivery where we can maybe even approve at a feature level. So we always talk about shifting left.

How do we shift some of those approvals left? And that's when we start to move down the maturity model. We can gain conviction that we can do that reliably. Right? And then, ultimately, what we're trying to do here is ship faster.

Right? From a development perspective, obviously, all the engineers, developers we talked to, they wanna make sure that their, you know, their code actually reaches, you know, production. You know, it's actually used. So how can we get this faster, into these into the regulated spaces and, you know, moving from that baseline where we're seeing annual as maybe that release cycle to something as biweekly or faster? And and, again, everyone's on their own journey here, but this is a useful framework for you to to self assess and and see how you can kinda move the needle, based on where you are.

Alright. There's a lot of talking from my side. You know, this will be recorded. We're we're gonna take a lot of questions here, you know, as they come in, as well, but would love to hand it over to Bailey at at this stage to talk a little bit about the AI native SDL SDLC. Yeah.

Thanks, Tim, for that overview of the AI maturity framework. And now we can look at what this looks like in practice. So what you're seeing here is that AI native regulated SDLC and what it actually looks like. And for those of you on the call, you could probably recognize that these are some of these agents that you're actively trying to deploy in your SDLC today, whether that's at the entry point, so your systems engineers trying to write requirements with an agent to not only help you create a new feature but also analyze your existing requirements to find where do you add where do you have redundant or conflicting requirements? Or am I writing high quality requirements that are actually testable?

Do they have acceptance criteria? Those types of things are great use cases for AgenTeq workflows. And then down the pipeline here, can see many different opportunities for ways to deploy agents across your entire SDLC. And what you end up getting is one big SDLC transformation with AI embedded at each stage. And a key point here is that humans are reviewing and approving at every decision point along this SDLC.

This is what Ketryx helps you get to. On the next slide, you'll see some of these applications of AI across your entire regulated s l SDLC. In talking with our teams, we found dozens and dozens of use cases of how teams are thinking of applying these agentic workflows, from the requirements one that I mentioned at the beginning all the way down into the source code where your teams are probably already actively using tools like Copilot to help them work, and then along with doing a change impact analysis. That's really where or these three here are really where we're seeing a lot of teams find interest. And then, Tim, can you hear me okay?

I saw in the chat that maybe someone lost sound. But Okay. Great. Just checking in there. Awesome.

Yeah. So amongst these dozens and dozens of use cases we found, I'm sure there's hundreds more, and there will be more to to come up as we start to implement this in our complicated SDLC. The three here are the ones that we are actively helping our teams with today, you know, from requirements, implementing those requirements directly into the source code, and then also running that change impact analysis across those items, which is a really complicated process today. A lot of teams, a lot of stakeholders involved in that change impact. So let's dive a little bit deeper into those three use cases.

We'll first start out with that requirements generation and quality review. Teams spend a lot of time today translating market needs into testable requirements. This can take your teams months just in that first phase of your SDLC, writing them, making sure that they're of high quality, translating them into something that your teams can actually implement, and then, of course, throwing it over the wall for the software developers to implement. And there's a lot of time spent in that translation of what the product must do and how it actually gets achieved and then also tested. What we see with teams that are using Ketryx and our Ketryx AI is that they are doing this about ninety percent faster.

And that is some real data that we've heard with teams and maybe even on the generous side. I'm sure teams on the call today are already thinking of ways that they can use this, whether that's, you know, copying and pasting it into your preferred LLM to help you write requirements. What we do is we bring that directly into your SDLC so you're not jumping tools. You're not shifting context. The next use case we'll take a look at is the design controls or code from design controls.

So after you have all of those requirements, you've deployed agents to analyze those requirements for redundancies, for conflicts, to make sure that they're written in a testable way. You then need to implement it. And so your teams, like I said, probably have tools that are helping them implement this. And your developers may spend a lot of time translating, whether that's from a different language or just trying to understand what it was actually meant when someone wrote this. Maybe that involves contacting contacting a subject matter expert.

Maybe that's a SME to help understand, you know, is this what I'm implementing actually what you wrote it to implement or what it shall do? With our AI capabilities and with Ketryx, teams are moving a lot faster, having less rework and shipping with higher confidence because we give your teams these tools at the beginning. So shifting left compliance AI capabilities as they're working instead of at the end. And third, what we'll see is that change impact analysis. So once you've written your requirements, you've written the code, and maybe now you're trying to understand what is the impact if I actually implement this feature.

Or perhaps you're late in your VNB cycle, and you've now found a defect or a bug. And now you need to go back and decide, can we create a feature release, or do we need to create a hotfix or incremental release to go back and patch this? Or does this, you know, put our timeline, our release timeline at risk? So your teams are manually going through that process today, identifying impacted requirements, impacted tests that need to be run, and trying to do all this manually across tools and across teams. With Ketryx AI, what we do is we empower your teams with that ability to run an agent that helps you understand that impact.

So surfacing those impacted requirements, tests, as well as risk items so that the time spent going across tools and surfacing that goes from hours to minutes. And sometimes we talk with teams who are doing this in weeks just understanding what is the impact of this change. That typically results in about seventy percent reduction in change impact documentation time using the agentic workflows that we supply teams with in Ketryx today. Okay. So with that, let's take a look at how these are actually implemented, how do we do this in the Ketryx platform.

We'll go through those three use cases, and feel free, of course, to ask any questions in the chat. Can everyone see the Ketryx platform? I can see it on my screen. for those of you who haven't seen the Ketryx platform before, welcome. For those who've seen it, welcome back. Here, we're going to be focused in this insulin delivery monolithic system, which is the main work or tools that the teams are working in for their SDLC.

And you can see the tools they're in are Jira and Git. Ketryx really can connect into any tool that your teams are working in your SDLC. We're pretty much tool agnostic. We connect to the tools that your teams are already working in to automate the processes you already have in order to enforce compliance. So we're going to do we'll see some of those use cases that we just discussed, those three, in action in the platform today.

We do, of course, support a systems assistance workflow, which we won't dive into today for simplicity's sake. But for those who are interested, we're very happy to talk more in-depth in a in a future conversation. So let's jump in. Going into this insulin delivery system, you can see this item based workflow that we're working in. Ketryx creates requirements, software item types, requirements as risk controls, which is pulling those different items from the tools your teams are working in, whether that's Jira, Polarion, JAMA, DNG, or Git.

And this item based workflow is how we increase speed without compromising compliance. Once we create items around each of these different item types, so items from, you know, six to three zero four, whether that's a change request, a kappa, a test plan, a bug, or risk item, we can then enforce an approval group. So we can or an approval order. We can require different approval groups to approve this item. So for this requirement, we have four different approvals who need to approve this item, and that's an automated process.

So a lot of time is spent today for teams manually trying to, you know, push along requirements into the next phase in their SDLC or get the next approver on it. With Ketryx, we take your static QMS and approval rules, and we make it living. We bring it into the tools that your teams are working in to automate your QMS for you. Similarly, you can see around the software items that we have only two approval groups. So another way that we can configure different approval orders around different item types.

We then also have different states around items. And so when your item is in an approved state, it's immutable. And Ketryx can help you enforce those part eleven approvals directly within your items. You can do that by, you know, creating your biometric signature, which will then automatically move an item from resolved into a closed state while keeping that full audit trail. So we can click into an item.

Maybe this item lives in DNG, Clarion, Java, wherever your teams are doing their requirements management. For teams in this example, that's gonna be in Jira. And you can see without having to click into that tool, the description of the item, different standards that it complies to, as well as the traceability for that item. So this is traceability that's being built within the tools your teams are working in. And you can click into different items here to view the in that side panel, the different items without actually having to click into the source system.

Once we've itemized the work your teams are in, we're then able to build this real time traceability. So this is end to end traceability from requirements down to software items that can live directly in the source code and then back to verification and validation testing. Typically, that can be across three different tools even, where from a requirements tool to where it's implemented down to maybe a different test tool for your teams that are doing both manual and automated testing. With Ketryx, this is a real time traceability that's being built with computational controls at the top to help you understand where you have gaps in traceability as your teams are working. So clicking this design input that shows me this design input control shows me where I'm missing coverage with design outputs.

And here you can see about two requirements that still need to be implemented. Maybe we're implementing a new feature here. Once we are able to see where we have gaps in traceability, we're shifting this left. We can then go to the releases. So Ketryx allows you to work on consecutive releases simultaneously.

And let's jump into the two point o release since that documentation. So we saw the items that our teams are or the tools our teams are working in, the item based work, the traceability. What that builds up to is the documentation that automatically gets generated as your teams are working. You can generate all of these reports with a click of a button, which will pull in the most recent changes from those tools. So we're automatically generating or pulling information into these pretemplated documents.

And it's a very customizable templating that we used to generate all of these, which you can then download and view for your teams. So when it's time to create a DHF, it really is the same time that your code is complete, that your DHF documentation is ready because Ketryx is connecting to the tools your teams are working in to automatically create this documentation while enforcing compliance. So now that we've seen the end to end workflow of what is Ketryx and how are you building an automation, let's start to look at some of those use cases and AI workflows. We'll go back to our all items screen and start interacting with our AI assistant, which is in the top right hand corner. This is more like, you know, your copilot that also is embedded into not just only a copilot that you can ask questions or your companion, but I can also help you execute really complicated workflows.

Let's start with writing a requirement. So we're gonna start with that first workflow, which is maybe we want to implement a new feature here. And this new feature in this insulin delivery monolithic system is for maybe meal announcement and structured bolus workflow. By interacting with the assistant, it has all of the context of the information that lives in connected systems. So in this case, that is Jira and Git, but it can be any other tool that your teams are working in.

It can be information that is in your QMS, so maybe any documents or relevant information that you wanna provide. This is how we provide accurate results. With AI, context is everything. That's how you get better results and accuracy. And Ketryx has that context using the knowledge graph, which is the traceability, to allow the assistant to understand not only what exists but the relationships between items.

So we've written this item with the assistant here. And what we'll do is review this suggested item together. And this requires that the human is in the loop. You can make edits. You can change acceptance criteria.

Maybe you want to update specific fields here. In this case, I'm just gonna go ahead and create the item. This requires all humans to take action or review everything the assistant is doing in your system with audit logs showing every single change it's made. So we can click into that item here. We can see the details, and we can see that this item was also created in Jira.

So the assistant, we just go ahead we went ahead and created work that is visible to teams in that connected system. The next thing we'll do is we'll see how your teams, so your software developers, implement this work. And we'll do that by using our MCP that's connected directly into our CLI. So I'm gonna click into this item here, and I'm gonna go directly to Versus Code here. What I've done is I've actually pulled in my Git repo where our teams are working, and we can start interacting with Clod, which is connected to our Ketryx MCP to start understanding what's going on in this system.

So this is the developer workflow. What we just saw was our systems engineers implementing writing requirements. You can even review those requirements for the three c's, completeness, correctness, and consistency. And now we're looking at the developer workflow. So now they want to implement it.

By staying in their CLI and using our MCP, they can understand those requirements no matter where they live. So for example, I just asked here in my CLI, you know, what requirements here are ex oh, yeah. What requirements discuss alarm systems? And so we can see all of the different items that live here, and these are those Jira items that live in our connected tool. These can be items that live in DNG or Polarion or JAMA or wherever your teams are writing requirements.

So, again, your software developers do not have to leave their preferred tool to get information about the requirements or features, bugs, or defects that they need to implement. They can start interacting with it and understanding what needs to get implemented. Now we can start to implement that new requirement that we just created. So now I'm going to tell the assistant, okay. I'd like you to help me write some code.

So typical to Copilot that your teams are probably using to help them write code today, we're going to use our MCP to call our Ketryx demo environment, so that insulin delivery system, to grab the item that we just wrote together and then start to understand the not only what is the context of the item, so what was the description, what is the acceptance criteria we wrote, but it also understands the relationships between items that exist. So that's that knowledge graph again that I'm referencing on that traceability screen that we saw. The traceability matrix today is a report that your teams are generating to be compliant to specific standards. With Ketryx, that becomes a knowledge graph that allows the assistant that allows Claude to have more context on the work that's being done. So I'm going to make this change here.

We're actually going to write this new TypeScript function, which you can see was written directly here. It of course, we're going to want to review this and make sure that this is exactly what we'd like to implement, which you can review and do here. Now I'm going to commit and push this, and we're gonna make sure that we have the correct branch. So I'm just gonna grab that from Ketryx here. Branch.

And, again, this is how we keep your teams working in their preferred tools. So your systems engineers can stay working in their preferred requirements management tool and Ketryx to understand that knowledge graph and use AI capabilities. We're gonna require approval here. We're gonna proceed. And then we're going to be able to see how this gets connected back to Ketryx.

You can see by user m c MCP that we're able to commit and push directly to the bridge that we're analyzing for that new TypeScript function that we just wrote for that requirement that we wrote together in real time. Now going back to Ketryx here, we're just going to do a quick refresh from Git, which is a real time sync. And you can see here, here's that new requirement that we created together. And then we can take a look at that item directly in our repo as well. So going back into our repo here, we can then start to see all of the items that are being pushed back into our repo as well as that TypeScript file.

Before we take a look at that any deeper, we're gonna finish that final workflow, which is the change impact analysis. So going back to Ketryx, we wrote the requirement. We wrote the oh, here's that software item. We can take a look at that in just a second. Now we want to do the final use case, which is the change impact analysis.

So I'm going to, again, interact with my assistant here. Just gonna ask it to perform a change impact analysis for implementing this new feature for and I think it was that meal announcement and workflow. So this is our final workflow, which starts to build off of, you know, AI being more than just a companion. I would say this is getting into our run speed here where we're using this and kick starting multiple different sub agents to take action on our system. That's taking the persona of the systems engineer to analyze impacted requirements, the software developer to understand impact in code, your tests and quality team to understand impacted tests, and, of course, your QA and RA teams and the need to understand what is the risks.

So if we wanna implement this new feature here, we can ask the assistant to do a change impact analysis. And you can see here that I've asked it to do a more simple analysis for this demo for you that just looks at requirements, risks, and test cases. So utilizing this knowledge graph here, which is our traceability matrix, we're able to take a look at the impacted requirements. So here you can see that this dose suggestion calculation has a suggested edit for this new feature. Looks like we have some risks that need to be edited.

Or perhaps maybe there are new risks that are introduced if we implement this feature. And is there a new test case, or do we need to update a test case to implement this new feature? All of those can be implemented to you. And then, of course, you can take it a step further and have it suggest these items directly or suggest these changes directly to the item. This is a very common workflow, I would say, that we're working with teams on is that change impact analysis workflow.

You know, if someone were to ask me what is the most, you know, common use case, I would say it's that one. And the reason for that is because it's it's so complicated. It take it really does take teams weeks, if not months, to to understand a really complex change for especially for a complex system. And so with Ketryx, they're, you know, using or using these automations to understand what are the changes, what are the impacts to surface the information, and then also make those changes directly in the system. Yeah.

I think, Bailey, you've heard before. Right? One line of code change doesn't necessarily reach the field until, what, six months, three months, you know, depending on that. So I think that that impact analysis, obviously, critical use case, great use case for AI here. Yeah.

Exactly. So we can review these suggested edits to existing items, and we can see exact red lines and green lines of those changes. So I've been talking about audit trail, and here's where you see that in action. We keep, you know, exact red lines of every single change that gets made to your system while keeping the human in the loop. So you're going to say, yes.

I agree or maybe I don't agree and make some changes here. We can save those changes to the items and see the updates being made to the items directly even in their connected systems. So Ketryx does have that bidirectional sync with all of these tools so that any updates that you're making here, whether that's using the assistant to make changes or whether that's doing approvals, you can see those changes reflected directly in your connected systems. I clicked one of those suggested items here. And what I wanted to highlight is what we're seeing is an enforcement of a process due to some of those changes.

So in parallel with using that assistant, we also have some computational checks that help you understand or deterministic checks that help you understand change. In this case, we have a flag here that says, if I make a change to a design input, I want the design output to be flagged automatically so that I know what changes are relevant in my system. So that's what we're seeing here is that your users are notified if the design input has been updated. And we want to analyze those changes so I can take a look at what those changes are and make sure that I agree with the changes. And so as your teams are working across many different components, maybe you want to have this reverification flag in place so that as your teams make changes, you can view those changes with red lines and green lines and decide if, okay, that was just a syntax change.

It doesn't change the content of my system. I'm okay with that. And that allows you to dismiss the change if you believe that, you know, this is just a syntax change here. So there's the rationale for why I believe that this is an okay change. So can dismiss that, and then you see that flag go off.

So what we just saw was a combination of using AI into a complicated workflow of a change impact analysis using both deterministic and generative AI to do that. Alright. Oh, yeah. Go ahead, Tim. Just really quick.

There was a question that came in relative to the the demo. Question comes in. It's, is it just keeping the latest version or more version of change? If I perform change once more on this issue, then how will it be tracked in the history? So is it just version or, you know, that kind of version control piece?

Right? Great question. And let's take a look at versioning. We only touched on it on a high level, but I think it's a really important part. So for any item here, you can see we're looking at the Ketryx record.

We're viewing the traceability down below. And with every item up in the top right next to that helpful AI assistant is our three lines here that you can select that shows you that approval order, so who needs to approve the item, as well as a full history. So each revision is what we call changes to an item within a version. We keep a unique identifier as well as the revision history for every single change. So whether that's changing it through a state, which you can see the state changes here, or whether that's making a change to controlled records.

We keep track of both, allow you to filter down on those control records. So maybe this is something you would show to an auditor. And then you can click into this diff icon, and it'll show you exact red lines. So we keep track of versioning within items. This is what we call revisions, as well as versioning at the release level.

So within each record, you can see the exact version history. But on the all item screen is where you start to see the versioning across releases. So on the all item screen, we're comparing two point o, so that's that current version we're working on, to a previous, you know, patch release, one point o one. And this diff column here shows us exactly what's changed across versions. And this diff icon shows you again those red lines and green lines, and this plus icon shows you that we've added some items that are new.

Maybe we've implemented a new feature in this version. This allows your teams to very easily understand what's changing across releases at the all items screen. And then when you click into a record, you can see revisions within that item. Excellent. Yeah.

I think we, yeah, we just had, you know, maybe a a general question, and maybe, Bailey, I'll I'll tee this one up for you. And Yeah. Like to get your thoughts in terms of do you think of Ketryx as a pure ALM, or does it also cover PLM from your perspective? And, you know Really, I think it's both. That's the answer I would typically give teams.

We connect to the tools and and that your teams are working in to produce your release or your produce your documentation. So we work with teams who have both hardware and soft and software components and really complicated devices as well, whether that's a robot that they're developing, whether that's an insulin delivery system. We have many different spectrum of products that we help teams with that have both software and hardware components. Yep. Yeah.

I think that hardware and software combo Yeah. Definitely a critical piece. Yeah. And question. Yep.

Oh, yeah. Sorry, Jazzy. I saw that next question that's related to versioning, so I'll just grab that one while we're still talking, or while versioning is close in mind. Yep. So we saw versioning at the item level when in an item based workflow.

We saw versioning across release versions on the all items screen. And now we're looking at versions on releases. We can manage multiple release versions in Ketryx simultaneously. So as your teams are working on two point o, they could be working on incremental release or consecutive incremental or major releases at the same time. So if your team is working on two point one, they had any time can go look at two point o or go back and look at a previous release version.

We can go take a look at our two point one documents here and pull in all of the different items that live in two point one into our documentation. So at any given time, you can see any export for any different version of your system. So hopefully, I answered that question. Great. Yeah.

Yeah. Maybe I'll go back to Lisa's question, if that's okay. Sure. You know, answer this one live. So, you know, great question.

The question is, you know, we advise to have a dedicated AI owner. And what qualifications or experience would you advise for the specialist? They're and software is a medical device. So it's a really good question. I think the reason why we haven't seen this role, you know, specifically become one person is because of how complex it is.

And that's why we think about the pod where you have multiple folks that have really strong expertise in regulation, in QARA, also on the technical side. Right? So from the engineering perspective. And we see this maybe the specialist more as a connective tissue. So they understand SDLC six two three zero four.

They can kind of, you know, kinda govern, you know, these some of these use cases that that Bailey is mentioning and help be that connective tissue, right, between, you know, the the technical side and also the the quality and the regulatory side. So I think you're gonna see this profile actually emerging more and more, this AI specialist. But if you can't find this unicorn, this AI specialist who has this technical acumen and also the QARA perspective, the pod can work, right, where you can bring in multiple specialists to help own it. The one thing with the pod is just make sure you have clear monthly objectives with what you're trying to to implement, and and that's what we see is super successful. So for instance, if if change impact is what you wanna release, you know, that's that's something that, you know, you know, should be a focus for that pod for that for that month just as an example.

Yeah. One one other thing is Ketryx is a validated platform. So we have our validation package. We're certified by UL to standards like six two three zero four, one three four eight five, and one four nine seven one. We're we are happy to provide that validation evidence to teams.

And, typically, we don't see any additional validation that's needed on top of that. But if it is, it's very minimal. Amazing. Awesome. Well, hopefully, that was a helpful, you know, entryway into how teams can go from AI curious to AI native.

We talked in-depth at some of those use cases that we are actively helping teams out with today. If you liked anything you saw or wanted to discuss it further on how you can use Ketryx and start using AI in your workflows today, feel free to reach out. We're happy to talk more with you. And up next is our another webinar which was sent in the chat, so feel free to attend that next one and share your experience here. Here's a QR code if you'd like to fill that out for AM maturity and compliance benchmark survey.

So thank you all so much for attending. Really appreciate it.