Name: From Code Abundance to Delivery Confidence: A Product Walkthrough
Uploaded: 2026-09-16T07:16:15.694Z
Duration: 49 min 8 s
Description: From Code Abundance to Delivery Confidence: A Product Walkthrough

Transcript for "From Code Abundance to Delivery Confidence: A Product Walkthrough": Hello, and welcome. If you have already joined, go ahead and tell us where you are from in the chat wherever you are in the world. That would be nice to know, and maybe give us one or two things that are giving you the problem day to day related to your SDLC or delivering code to your production. That will be nice to know about yourself. Looks like they're joining. It'll give one sec one or two seconds more. Hello, and welcome. Alright. Let's so without further delay, let's go ahead and start it. Once again, hello, and welcome. Thank you for joining us today. I'm Manu Tyagi, a senior solution engineer working in Cloudbiz here, and I am joined today in a recorded session by our three product leaders who actually built what you are about to see today. A quick honesty upfront, if you are here, it's probably because something about the last twelve months has not been added up. Your developers are shipping more code than ever. Your AI assistants are writing the real production code. Your dashboards are still mostly green. And on call rotation, it's and the call rotation is busier than ever it's been there. Right? So the gap between what the tool says and what production actually does is the entire reason that this session is all about today. So today is a product walk through, not just a slide deck for product, for the entirely. I do have a few minutes, ten minutes of context, then we will spend about thirty minutes in the product, and we will have time for q and a. And the one question we are gonna answer in different ways that you probably would notice it, are we safe to ship? Right? So the three product leads driving the portion of Cloud based Unify are with us today in a recorded session. As I said, I am Manuj, your host today. Jack will walk us through the smart test. Ewan will be covering the governance and the control plane, and Jordan will be closing with AI assistance. And here, the shape of the next fifty minutes. First, why this problem is structured, not just a tooling gap. The second, architecture answer in one slide. Third, we will have a demo, which is most of the time most of our time in the session today. And we will end up with three specific ways to start in hours, not in quarters. And, definitely, there would be a time for your q and a. K? So the gap is real and is accelerating. Every tool, every process, every org chart in the software were designed around one assumption, that writing the code was the expensive part. But that assumption is gone. AI writes a code faster than any team can review, secure, and validate it. The bottleneck did not disappear. It just moved. It was actually used to sit in front of keyboard. Now it sits in front of release. And if you remember one sentence from this from this deck, make it the blue one. That's highlighted in the blue color. And we're gonna talk too much more on that. Right? So this is not a new concept. It's about your org. Your org already have it. The code comes in one end. The business value is supposed to outcome from there from the other end, and you write the code for a reason. Right? So software is not a goal. It actually the outcome of it is the goal. Right? So you may call it or not, but it is a factory. But you have inputs there. You have, like, inputs. You have handoffs. You have outputs. And the only question is whether it is an efficient one or not. Right? So I just wanna highlight here, this is a factory everyone draw on the paper. Obviously, you probably would have done that as well, whiteboarded on it. It's a linear, predictable, in instrumented with commit to productions, and most organizations generally set out to build this one. The real estate target is not a perfect straight line. It is a factory that we call call it a software factory with a feedback loop, shared visibility, and a governance building. This is achievable today. The teams get there when orchestration and insights span the whole tool chain, not just one CI server or one scanning tools like that. Right? So in here is where most actually are. The tools, pros, duplicated pipelines, and the compliance bolted at at one end. And, interestingly, nobody actually have designed this. It actually accepted or aggregated over the year with the with the technical debt. And with AI pushing more code through the factory, the inheritance or inefficiencies are compounding fast. Let's look at some numbers. So 213 enterprises survey been done with the tech leaders and and the their phone number that we're gonna talk today, starting with the 12 person. The organization with the dedicated AI governance are in that category. There are 88 persons who are actually improvising, and most most of us are no. They know about that. Right? Now let's connect that to the 81 person who actually have already shipped a production failure a production code, which had the failure into which has been generated by the AI. And to be to be honest, this is not a hypothetical. This is a survey. There's an incident report, and you available there. The improvisations has a cost. Right? And it's already been paid. So bottom line, the bottom the bottom row is a bill that CICD spent climbing for over half of them. And none of them, like, I will say the zero has reported is going down. Right? So test maintenance, eating more time than writing the code in the 70% of the cases. The AI productivity win on the left side, but the cost shows the code shows up on the cost on the right side there. Right? Now look at the look at all the way right there, the maturity. The maturity app today is like AI guides, and most of us most of you are there. Next, AI is doing the drafting. Right? So some of you are piloting already there, and there is an AI act inside those policy that something is pretty much outside available or maybe is ready to move on in. Right? So here's the move. A gap in a system where human moves in seconds in one category of risk, the same gap when agents move is in milliseconds is is not the same category, but of a different category. That two hour slack that we normally integrate or discuss about is stitched together for every release does not actually survive this handoff of AI. So that's the that's basically the diagnosis. So next slide, we're gonna talk about what it means in your day to day. So there are three tools. So three green signals, one blocked phrase, and no signal tool can tell you why. So Jenkins says there are 392 tests executed for hundred and two minutes. The GitHub says the PR merge with all green, checks green. The scanner says no critical issue. All true, but, unfortunately, this is incomplete information. And here's a choice in front of every enterprise engineering team right now. Look at the left. The single vendor platform give you a CICD, a feature flag system, a test management tool, security scanning, release operations, analytics. The component looks quite familiar. Right? The pitches add one platform and one throat to choke. But what gets lost when you migrate is everything outside to that platform. You'll lose the build context, the code history. Right? The security posture, the feature flag states, all left behind, or you need to rebuild that. The dashboard goes green. That's the platform telling you it can't see what it's missing. The green is but the green is not the same as ready. Right? And that's the answer we're gonna have this slide this session. Now look at the right. Cloud based unified gives you the same component, but they sits on top of a control plane. The same policy, same RBAC, same audit for human and for AI. Here's a part of the architecture argument hangs on. The integrations are not the differentiator. Everyone integrates. Your CI sees your pipelines. Your scanner sees the CVEs. Your SCM sees a PR, and they are all same see something. Right? What cloud be what unified does it, it reads across them. Looking at the bottom of the slide, you will see that, and this a reality of the most of the organizations. The 12 CI tools, 10 deploy tools, six source control systems, six artifact registries, 27 secondurity scanners, all connected, all sharing one delivery card. So every tool sees its own slice, and Unify knows what it all means. That's what it is. So let's see let's look at a for a particular example. Jenkins, this time, says there's a 9098% test pass in thirty minutes because of smart test. Right? The GitHub say the PR merge with all checks green. The scanner says no critical issue. All all true again. All can but the point is all incomplete without a context. A control claim that's connect them. The PR deliver a feature for a component used in three applications. The build that passed also pulled in high CBRE CVE that blocks all three from the production. The other 294 tests did not matter because they were not related to the changes being done. The scanner gave the all clear because it ran on the wrong dependency version. Right? So every vendor integrates with your tools. We are the only one that contextualize, and that's very important across them. That's why the AI can answer, are we safe to ship? And now let's see it run. So three scenarios that we're gonna talk today in the demo walk through, and one question we're gonna answer it. Each segment run its own environment, but you are watching the same story from a three different angles. The first scenario, the code changes are happening quicker than ever, and your developers, with the help of AI, ship the code changes with few with the all new tests. Which one actually matters for this build? That's the question. And the smart test answered it with the added benefit of a 70% or seventy minutes execution time reduction in this scenario. Jake will walk us through on that. The second scenario that we're gonna talk today, the code is ready to ship. Centralized policies automatically gate every deployment so governed delivery is not a process managed per release. It is actually enforced by default. And everyone will show us you the the governed release workflow, orchestrating an application deployment across different environments gated by the policy, progressively delivering feature through the flags, and producing a complete audit trail that write itself. And the third scenario we're gonna see there, the releases is is kind of a mid flight, and there are the security security issues being investigated and suddenly the bill breaks. Right? So Jordan will show us how an engineer can jive in with the help of Unifi via either via AI assistance or the Unifi, UNIFI MCP directly from their terminal to understand why this why this kind of breaked out. Alright. So now let me play the recorded product walkthrough, and we will start with Jake followed by Evan, and then Jordan will take her to the towards the end of that. In my portion of the scenario, me and my team are building, testing, and responsible for one piece of a bigger release that Yvonne will be releasing in a bit. I'm going to start in the test sessions tab and I got here from the notifications that we have set up in both GitHub and Slack. We had changes come in from our team and our pipelines kicked off. Looking at test run two test session here, and a test session is just a list of tests and their timings, their status, and aggregate statistics, and in this scenario, a one to one relationship with the build. At first glance, we can see that this build in session was on the main branch. The end to end test suite was executed and was tested on Linux and Java 17, which is the build I'm looking for. We can also see that we had 18 failures, five identified flakes, and three issues. To boot, we also saved seventy minutes on this build. Let's take a more granular look at this test run two. In particular, this predictive test selection box. Here we can see the request. Our full suite usually takes one hundred and two minutes with a confidence target that we wanted to run. In this case, 80%. Smart test predicted test selection returned us a thirty minute subset of only 98 classes, which is the right sized and correct test to run for these particular code changes. You may be asking, how did you land on that 80%? Well, through observation, SmartTest generates a confidence curve where we can see that the additional seventy minutes of execution time doesn't really bias much in terms of value and we have confirmed this through our own analysis that, with the sessions and builds that have run-in observation. And you can do this with yourself with the slider at the bottom to analyze and find the optimal zone, that you want to be in and your team wants to be in. So if we go back to our test session here to look a little bit more detail into the failures, we can see that we have individual failing tests and their logs. And we can see that flakes have been identified. And 18 test failures might feel overwhelming. You know, that might be a small amount to some of you, right, in your experiences, but you can totally imagine having even more than 18. So smart test summarize these failures into three root cause issues, and we can see them here. And this is a lot easier to tackle and much clearer context for a developer or as someone responsible for driving these ever increasing changes into production. So we went ahead and addressed these three issues and reran the build. Let's go into test run three and you may be a little bit skeptical. Well, how do I know? Let's go into the analysis, the predictive test selection analysis and confirm what tests were actually selected and ran. We're looking at test run three here and this is a successful run. There were no failures. What you see here is the total list of tests that were in the suite, so three ninety two. We have the test cases that were selected in the response for the subset. Below that table, we also have the remaining tests that were not selected for this code change. One key point to key in on here is this density score. And, essentially, for sake of time, let's say, the lower the number, the lower relevance that these tests had to the particular code change. And if we go back to the ones that were selected, the higher the number, the more relevant these tests are to the actual code changes that were in the PR. So not only did smart test help me identify the root cause of multiple test failures in a much clearer way. It also saved us one hundred and forty minutes of execution time and compute by selecting the right test to get results of these changes quicker. So I am now confident much quicker that this is a great candidate build And I can confidently say from our team's perspective that, yes, we are ready to ship. And this is exactly the kind of expediency and accuracy needed in the age of AI and code abundance to release value to your end users and deliver with confidence. So speaking of delivery, I will pass it to Yvonne now who will cover the governance and control plane aspect of the Unify. Yvonne, take it away. Alright. I'm getting my demo loading, hopefully. There we go. So thanks a lot, Jake. I, you know, Jake showed you the testing. And with testing now complete, we are ready to ship. So, you know, Jake talked about the abundance of code. And what more code means is, you know, there is more to ship, and releases need to keep up with the speed of code without compromising the quality and the governance that is in place that before you get your, code into production. So how do we prevent those AI generated failures in production? And this is a challenge that many teams have today. Governance exists, but it might be fragmented. It might not be consistent across every single process, and audit evidence is scattered across dozens of systems. So in those compliance scenarios, there's a lot of gathering and looking for everything you need. And none of this is built for a world where AI agents are acting alongside humans. So what I'm gonna show you today is governed software delivery where centrally managed policy is enforced across all releases in the organization, and every actor is held to the same standard. And the audit trail actually writes itself along the way. So I am starting right now in the policy engine. This is a new capability that we're currently bringing to Unify, and we'd really love to have your feedback and input as we continue to develop this. So we would love to invite everyone here to join us as a design partner to help really craft this capability to, meet all of the needs we have for with AI, code abundance. So here in the summary view, we have all of the governance policies across the platform. They're defined and managed centrally. And rather than each team controlling their own workflows and policies, everything is defined and enforced here and governs all delivery across, you know, activity across the organization. So in the view, we can see the policy activity. We can see trends, how many policies exist, the distribution of how policies are being enforced in our workflows, as well as, you know, the policy health itself. What I will do now is go into the specific policies we have defined. You can see these are policies in place to block or or gate our workflows that take our releases into production from continuing, from promoting to the next stage, requiring certain thresholds or conditions to be met. So you can see a few of these were requiring that a security scan has run, requiring a production approval before we actually promote into production environment, looking at CVE counts, image scans, so many different options of taking the outputs of what is being run, the all of the context that we have in our Unify system about your application and gating, deployment into production or through your workflow. So I'm gonna look at this critical CVE block, and I will go ahead and go into the details here. So this policy is pausing deployments and notifying the team if there are critical CVEs, that are detected in any of the dependencies, anything that is being deployed in the release. And we it's really easy to build out these policies. You can create these conditions, connect them together into a multi condition block that needs to be met for the policy to succeed. So in this case, I have critical vulnerabilities. You must have zero critical vulnerabilities, in order to continue your workflow. I'm gonna add another policy here. I wanna also look or another condition here where I can also, look at another, value. There's a lot of options that we pull in, from all everything that's running in your workflow. In this case, I'm still looking at vulnerabilities, but looking at high vulnerabilities and making sure that there are less than 10 vulnerabilities. And I'm gonna make this, an add condition, so both of these must be true in order for the policy to pass. There are different actions that can be taken if the policy fails. Right? If we don't meet these conditions, we can block the, workflow from continuing, but we can also have an option to have human in the loop. Let someone come in and review what happened and make the decision of whether to, continue the workflow or stop production deployment. Another option is warn. As you're introducing new policies, maybe you just want to give that visibility into what is, what's happening before actually taking action or blocking on different, events. We can, of course, notify those who need to come in and approve to make sure they're aware of what's going on in their workloads and that they need it needs their attention. So as I've mentioned, this is all defined centrally in the Unify system in our policy engine. And from here, we can define where did these policies apply, right, across our applications in the organization, across across our deployment workflows. So we have a number of workflows, that this, policy is enforced upon, including our prod progressive rollout workflow, which you'll see later as I'm, starting my release. And then finally, all of this is, generates a very easy to parse YAML, a representation of the policy as well as rego code that represents the policy. So it these are open policy agent based. So the OPA code is generated, and all policies can be managed as code as well. So I will go ahead and update the policy. It's now updated with my new, condition, and I think I'm ready to actually release my application. So let me go to releases. And Unify release orchestrates every activity that's involved in shipping, taking your multi component application, and deploying it across your multiple target environments. And this is integrating with all of your existing tools, automating handoffs between them, and actively collecting your audit evidence at every step. So, here, I'm going to start in my Meridian release, where the release details view here has the context, the full context of the release in one place where, first, we have the workflow that is driving the release, that is automating all of the processes, the parameters that drive that workflow, and then the manifest, which is really the payload of what is being delivered in this release. Exact versions of each artifact and dependency that is part of my application being deployed, that will be taken across my environment. So the manifest really becomes the blueprint of what is driving the release. Each of these artifacts can automatically be connected back to the related work items that are actually, defining the work, the features that are being delivered as part of this release so you can get full traceability and visibility into who, worked on these tickets, what is the current state, and actually then orchestrate updates to the tickets as part of your release process as well. The features that are being delivered might be behind unified feature flags as well. So all of the flags that are, controlling the delivery of these features are also connected to the release. So you can get visibility here into these flags, what is the current state of the flag in each of my environments as well. And then you can manage update the the flags as more features are added. And with code abundance, this becomes even more critical with feature flags really being, something that we require for any AI generated feature should be behind a feature flag that adds another level of derisking, that code getting into production where if there is an issue, if everything makes it to production, you can easily just turn off the feature with the kill switch in feature management. Finally, in our release, we see the policies. We saw all of the policies that are defined centrally. These are the ones that are enforced on my release. So I can understand what are all of the gates and controls that are in place that protect and control my release as it makes it into production. So I'm gonna go look at the workflow to see how this release makes it to production. So here is our staged progressive rollout workflow that is taking my, payload of my application from release readiness, deploying to QA, staging, and finally to my production environment. In each of these stages, I am integrating with all of the tools, orchestrating all of the activities that I need to to, that are part of this release, whether it's creating tickets, updating things in Jira, running security scans or tests across all of my testing tools, enabling my feature flags after deployment in, Unify, or connecting with ServiceNow to make sure we have a ServiceNow triggered approval that allows deployment into production. And after production, another step to actually progressively roll out, progressively deliver my flags into the production environment in a controlled, safe fashion. Between these stages, I have policy. So this is where my policies, are are visible and shown that this is these are the policies that must be met before I can promote into my next environment or stage of the workflow. So I can see between staging and production. I have a single policy that is, expecting a production approval before I can deploy into into production. But while I am checking my CVE counts between QA and staging, I wanna add another level of, check and with a higher threshold between staging and production. But rather than going back to policy engine to go and define this policy, set the scope, I'm gonna lean on our AI assistant to make this a little bit easier for myself. So I will open up AI assistant, and I get some contextual, prompts that can help me. And there's one that is just what I need, which is adding a check between staging and production. So I'll go ahead and check this. And it you know, in this case, it is understanding and recognizing that in other flows, I have critical vulnerability checks before I make it to action. So I will just say, yes. Please add the gate. And I have a new policy that's been created and added, right from here between my staging and production environment. I can see the details where I'm making sure that, critical severities cannot be greater than zero. So with that, I feel confident and ready to release into production, and I will go back into my release and get ready to run it. Now, again, before running, there's a lot of context that's available in Unify. I have implicit security scans running for every code commit that's part of this application. And before I just click run, I wanna get some visibility into that. And I'm gonna use our AI assistant one more time here and check on the security posture of my release. So, again, I have some prompts here, so I'm not I don't have to type. I'm gonna just check what is the security posture of my release. It's going to pull together all of those security, scan results for on the specific, versions of the artifacts that are in my release manifest. So I get all that visibility. I guess can go through this and really feel comfortable whether I can release or not. And I know even though I have a few risks that are being accepted, I have even more policy checks within my workflow that are can prevent anything critical from making it to production. So I feel confident ready to release. So I can go ahead and run the workflow. Instead of running it live, I'm gonna of running it live, I'm gonna show you a few previous runs so we have time for our other demos. So let me go into the runs. I'll look at a previous run that, where the policy was enforced between release readiness and QA with a pause and notify. So now as, you know, as somebody on the security team who got a a request in Slack, I can come in, review the results of my scans that are all available within the workflow, and decide, manually as a human in the loop whether I wanna continue to QA or not. I'll go to a another run-in this case where we actually had a policy enforcement that blocked, progression of my of my workflow between QA and staging. My high CVE notification failed, and so the the policy blocked progression of my workflow. As somebody who comes in to understand what happened, why did this not work, I can come into policies, I can go into the logs, I can see all of the details, understand why it failed, and get full clarity on what needs to be fixed in order to have this release make it into production. Finally, I'll look at a workflow that actually ran successfully. All of my policies passed. All of my deployments, occurred, whether via Helm or another tool across my different environments, and I progressively delivered my flags into those, into those environments, in production as well. So everything is green and looks great, but what if I, need to come back and, see what happened in the future? Every step along the way is generating data, generating evidence that is all captured as part of our, audit report. So I'll go back into my release. And if an audit event occurs, I can come and view the audit report where the definition of the release at run time is captured, exactly what was happening when this release was run, all of the same information we saw before. In addition to this, I'm collecting the manual approvals. Any manual intervention in the release, who was the actor, who what was their approval message. All of it is, traceable right here so you can see exactly who was involved, who touched this release as it made it into production. I also get visibility into the deployments that occurred across my environments. And any evidence that is generated from whether it's external tools or internally, we're pulling that all in into one place so you don't have to go hunting between Jira, between your testing and and scans to see the results. Everything is right here and available. And finally, we get to see the policies. We, see exactly which policies were enforced. So you have that, understanding and confidence looking back that, yes, all of my policies were run and checked before my code made it to production. So with that, you know, you're not reconstructing audit after the fact. You're not asking teams to fill out forms. Everything is one place and ready to view an export. So overall, in this moment of code abundance, it's really more important than ever to have this governance, on your release processes that detect and block any issues before they make it to production. So in this demo, I got to show you a few places where AI assistant, can help simplify the process here, make it easy, give you more information, pull in the context. I'm gonna hand it over to Jordan now who will show you even more, on how the AI assistant can bring this context together. Awesome. Thanks, Yvonne. So, yeah, you saw all saw the AI assisted and how it helps you in context in the product. I've kind of tag team with you in, you know, in this case, we were just looking at understanding your security posture in your application. I'm gonna switch up over into my engineering mode as an engineering lead to take a look at some, you know, the status of our builds a little more deeply. As I dive in here, I'd love to know from anybody. First, a reminder, throw any questions you got over into the chat, and then I'd also love to know what's what's your role in your team. Are you an engineering lead, and what AI tools are you using? I'm gonna show, Claude Code, as the the tool I use in the terminal, but I'd be really curious what's what you're using as well. So let me bring up. So here I am in Unify, and I'm starting my day off. I I ran through the assistant. I, ran a question around understanding what's the current state of our software delivery and metrics, And it took me to our analytics screen and helped call out some top points, and you can see, yeah, the we got a high failure rate on our workflows. It's also called out a few other issues I could dive into. But in this case, I wanna go in and take a look at why are these workflows, failing and not not behaving well for us here. So I'm gonna jump on in, and sure enough, we've got a lot of red going on on this screen. Hopefully, it's not too familiar for everybody, but I know every now and then we deal with these. So I'm going to take a look at this first project to understand why is the build failing. And I could go through and, traditionally, you know, we'll look through the logs, try to figure out what's going on, but you can see there's a lot of stuff going on here. So I'm going to ask the AI assistant to help me understand, why is this build failing. And, just so you know, the AI assistant's available top right corner of the Unify app on every screen you're in. Everybody that's got access to Unify, you've got the AI assistant available to you today. And we're gonna go ahead and say why is this build failing. Now it's gonna take a moment. The AI assistant understands that when I say in context to give a little more, detail behind that, the assistant is able to see what's on your screen and can understand help you understand what's there. So it's, in this case, looking at the logs that I was just looking at and able to make some suggestions on a little more deeply what's going on. I I personally find this more friendly to read than having to make sense of the log output myself. So you'll see here it's letting us know that there are some issues with maybe some imports and exports, and our feature flags are not necessarily set up quite right, so our tests are failing. So now I've got enough that I can use. I can go on over and, dial on in, to, you know, go fix this issue. So what I'm gonna do now is, actually, we're gonna change it up, and we're gonna go over to the terminal. And I'm going to use Claude code. Let me hit the right button to share that window for you. Now here we are over in cloud code. So to set this up for you for a moment of what I've got going on here, I've already run a prompt and got the output so you don't have to sit and wait for two minutes and kinda, you know, chitchat with me a little bit. We can dive right into the details. But what we set up is I've got Claude code running locally. This is connected to the Unifi MCP server. I'm using an open source projects, we have available for you all called the DevOps agent kit to layer in some extra skills that are basically for these purposes, we can think of them as prepackaged prompts. So what I've done is my environment set up, and I said, what is the release status for the Meridian projects that I'm working on? And cloud code, it's using this release status skill that came from that agent get project I mentioned, and it's gonna do some thinking. This uses the MCP server to communicate with Unify, and it's helping make some sense of these different projects in here. So we've got the payment API, the web portal we just looked at, and so on. You can see lots of red here. It's all failing, which is not good. If we scroll down, it'll also give me an analysis for release status similar to what Yvonne looked at from the Unify UI here from my terminal. I didn't have to leave. I could get some of that same information right in cloud code and get an idea of also, like, okay, how my feature flag's working and get a real quick summary of the status of this environment. And then let's just see real quick if this will behave nicely for us today. I'm now, so I've gone through, and we wanna take a look more deeply at that project. So I'm gonna use this triage command, and this will again run a skill that came with the agent kit to run a triage of looking over the logs and other elements for this project and, help us understand more deeply what may be failing. So instead of making you sit again and wait for this, I've got this prerun in the background. And so you can see here I ran the same command. And if we scroll through here, it's able to tell me where in the workflow run the failure first occurred. So we can see here on the run test step that that's where it's failed. And running a root cause analysis, this gives us that same info we got from the AI assistant in Unify, but but without having to leave the terminal, I was able to get to the same information here about what failed as well as, you know, it's done some other details and given me some other info, around the security posture like what Ivan was looking at a bit ago. So I am in my local environment. I could actually go ahead and with this, I could ask Claude Code to fix this issue in my code base. I've got this extra context here from the triage report and be able to dive on in. For the sake of time and getting to all of your questions, I'll go ahead and pause. At that point, we won't dive into that. But to recap a little bit of what I just went through, we with the, AI assistant, we meet you over in the Unifi UI with Unifi MCP server. You can connect to Unifi through your favorite AI tools. If you live in your terminal or, you know, even in your favorite coding editor, you can add in Unify MCP server and be able to have these same interactions, get some of the same info you would have gotten, without having to go over to Unify. So we'll meet you where you're at. The AI assistant's available now, though, like I said, everybody's got access to it if you've got Unify. And then, the Unify MCP server is available. There's instructions in our docs to be able to set that up. And then the DevOps agent kit is an open source repo you can start using today with some more prepackaged skills, the ones I showed here as well as some others to help you out. Looking forward, we're doing some more work as well on expanding our integration and other AI tools and such, so keep an eye out in this space. Alright. I'm back here, your host, and, I think it was interesting session for you. You guys have learned about the three different scenarios or three different use cases but answering the same question about are we good to ship or safe to ship. Right? So let's move forward in that and, and and I think few couple of more slides before we wrap up. But so, basically, just wanna recap what we have seen so far in the session. By testing what matters for every code change or code made, you're guided by the AI with reduced feedback cycle to developers or QA progressively releasing with a centralized policy for both human and AI and one tool to understand across all your tools in SDLC. So the worry what I will say there, yes. If we do like that, if we have a broader context across your tools, across your the whole tool chain that integrate part of an SDLC, like a platform like Unifi, then you can you can pretty much sure but they give you, or you can get the verdict say, yes. We are safe to ship. Right? So same context, same gates, same audit trail no matter, no matter who or what is asking and out there. Right? Now you're probably asking is or maybe thinking about it, how do I get it started on this platform? Right? So there are three specific ways to start with it. So one is, like, open source and self-service. So you are it's a free account, free Unifi account with the DevOps kit, what Jordan was talking about, on on GitHub, which is basically under the Apache Tutor or license. The same kit like AI agent, which one PR scenario was talking about, it is and Jordan was talking about, you can pretty much download and use it from github.com/cloudbiz. That's one way. The another the second one is the guided walkthrough. We connect to your real stack, your Jenkins instances, your scanners, your other tools, and your registries, and we show you how what UNIFI catches that you are currently missing today. And happy to connect with that. Three, and that's very important. I think we touched the topic in the conversation, the AI design partner program. So if you are operating at a global 2,000 scale and shaping how Go one AI delivery actually works in production, We want you to, in the room, come and talk to us. Right? And now let's look at some, let's take some time for your q and a. And I see some of the questions, over the chat coming in during the session. I will go one by one, and you feel free to type those questions as well that you have in your con you might have it. So we have some kind of open questions. And, the first question I got is, how is the confidence code generated? And if you remember when, when Jack was talking about the confidence, the confidence curve is basically measure on how soon the smart test can detect the failing test in your test suits based on their historical performance. The curve is basically built on actual pipeline data rather than a generic benchmark. So it basically take the data of what you are currently experiencing on it and then take it there. It's really a trade off between the balance risk versus reward. So if you want to run the 95 when you have a forty minute subset, which can give you 95% confidence, you may not want to run your hundred minute test suites across your pipeline. So smart test stacking the test sessions in a stand ascending order and give you the order of time to first to be failure out to highlight in there. The another question that I have with, in the chat was basically how the update policies communicate to teams. So as if you're if you remember, I'm always talking about the centralization of all the policy. The policy no more lying into Confluence page or in PDF. They are pretty much baked or inside the single platform that you can link there. So the policies are being committed build out and been available on the platform itself, and the team can use those policy in their in their release end processes. Alright. I can see there is another question out there. Is this, policy like, OPA behind the scenes? Yes. That's correct. So these policies are pretty much OPA behind and with, and everyone was talking about the code generations. We got a code back by Regal, but the interface is pretty user user friendly, the YAML, or you can use, like, a Unify MCP server, or you can use an API to create those policies, but that's pretty much behind the standard framework call OPA. And the follow-up on that is how do I version control the policy? The version control the policies are we are going toward the direction, so you will definitely have the policy attached to your source code management system so that you can have a more control on the changes. K? The another question I had is, how do you handle the prompt injections? What, Jordan was talking about, AI assistant, security threats, and everything. So AI assistant behind the scene, that's it's a set of AI guardrails that we are using it, and then an AI gateway that kind of backing out those interactions. So the release, any features, especially what we do it, like, we do our own AI. We do our own threat modeling processes, did a lot of validations and best practice around that. So there is a there's a AI guardrails pretty much inside big inside the platform. Right? And one more last question I can take it up before we ride before we wind up in there. Is there, can I choose an AI provider if I have an existing commercial relations with this? So I I answered this question in a two part. One is, like, if you are using AI assistant within the Unifi interface, then it's basically, we are tied with cloud. But if you are using Unifi MCP server outside to your connecting to your any third party commercial, you are free to use any commercial relation like Cloud or, Goose or anyone, that you want to use there as well. Right? So you are pretty much open to use any of those providers. Right? Alright. Let's give a pause. If you have any any other questions, feel free to drop in. If you have more questions, please send us an email or we can we can come back to you as well. And, if there's no further questions, we can go ahead and close it. And I would like to thank you for your hours. Thank you for time, and thanks again for your participation here. Thank you so much.