Name: Dataiku Reasoning Systems: Closing the Asset Performance Gap
Uploaded: 2026-07-16T16:32:18.349Z
Duration: 1 h 3 min 52 s
Description: Dataiku Reasoning Systems: Closing the Asset Performance Gap

Transcript for "Dataiku Reasoning Systems: Closing the Asset Performance Gap": Hi, everyone. So thanks for joining us today, to our webinar, Resideo System, Closing the Asset Performance Gap. We are really happy to have you today, and we so the objective of this session today, it's a one hour session. We'll cover how to transform industrial operation, by moving from manual reg process to scalable intelligence reasoning system. And first of all, I'm Ampea Butaub. I'm senior director for solution, at Adaiqoo, and I will be guiding you through this session. I don't sign my my teammates, of manufacturing an AI expert. The objective of this session is to provide you with a clear understanding of, what is a data acquisition system. A real world scenario, like with the demo, we do that at the end and what it mean in term of, a production ready AI, for resonating system. And we did leave some time at the end, fifty minutes, for question. During the presentation, don't hesitate to to ask a question in the chat. We'll go through it. If there are some quick question, we'll try to answer them, like, as we as we present. For the longer one, we'll, try to answer all of them at the end of the session. And if there are more more more question, we'll try to answer after the session. So now that I've introduced myself, I let, my colleague, introduce himself. So, go for it, Christine, Nicola, and, and Henry. Hi. Nice to virtually meet everyone. And, my name is Christine Andrews. I am, on Pierre's team, manufacturing and supply chain specialist here in The Americas, and I've been doing it for about twenty five plus years in manufacturing and OT. So I'll speak a little bit from that process engineering and OT lens to you today. Hi, everybody. Thank you for joining. So I'm I'm Nicolas, and I'm working as an AI solution engineer here in the team. I'm working on the technical side of things along with Pierre, Christine, and Henry. So I've been building, some of the asset we will, show to you today, and I'll do a quick technical demo, as well. And, happy to, to answer any, technical question you might have. Thanks. Hi, Taylor. I'm Henrik Morrow, working as an AI solution consultant in PR's team. I'm based in Germany and working with our various manufacturing customers mainly in, Europe, EMEA, and Asia. Happy to be here today. Okay. So so let's start with, some couple of introduction, and just to set the scene of what we are talking here. And, and then as we go, we'll go more into technicalities and the detail. And and, again, don't hesitate to ask questions. So what what we see today is that, when we talk to to our customers, especially, like, the one who are, like, facing industrial challenges, we see that, there are, like, really, like, a lot of pressure on them, And in particular, like, just like years, that's three key, numbers that we we have, like, some, some consulting company like Deloitte and McKinsey. We see that they are facing, like, a a big challenge in term of potential downtime of, that could cost them, like, 50,000,000,000, like, like, which is which is huge. There is also, like, obviously, like, a a big number of people, in the organization that's gonna be retiring. So we are talking about 3,800,000, manufacturing skilled people that are potentially leaving by 2013 search '33. And so this is a this create a gap in this organization in term of knowledge and and competencies. And there's also, of course, and this is what we what we're gonna try to showcase today, an opportunity, to improve, nicely, the way you work, and in particular, OEE, which is operational equipment effectiveness, to by just improving one percent, you can generate, 10,000,000 in, dollar in value. And and so those those are numbers. And what we see that there is clearly, like, a a gap, between the one who are succeeding and the one who are not. And in particular, if you look at, the slide here, on the bottom right, you see that the reality that many of our customer and many of of, like, people in this industry are facing, it's not is it it's not because the technology is not there. To be honest, the technology is there. AI and data is here. But, this we need to move like, as industry, we need to move from refragmented and reactive to one connected system. Because the reason of that is they have invested a lot in data and and those data are in the silo and different system, MES, ERPs, you like, the CAD system, PLM. And so all of this need to be consolidated, connected together. There are processes. There are many processes in in big organization, and those processes are are quite often fragmented. So you you need to have, like, more, like, a consistency consistency between all of them. Your of course, for this organization, there is a lot of knowledge that is a bit of knowledge which which we can consider tribal. So one expert engineers may know the asset, but the other one doesn't know. So when you leave, the expertise, is living with him, or her. So you need to adapt and you need to capture this knowledge. And quite often, if we focus more on the AI, efforts, those AI efforts have been stuck in pilots. So what do we mean by that is that quite often, like, what we see at our customers and what we see also in the industry that people are trying data and AI for improving their efficiency. And, usually, it works for a single line of production for maybe a single plant. It's okay. But scaling it to another production line, to another plant, or scaling it to one type of equipment that you want to to take care, like, when you're doing aftermarket, field services and scaling to a second equipment is is kind of complicated. So the our idea based on this, fragmentation and and this fact the fact that it was really reactive is that we we thought it was really important to create a new system. And this is why we're we're launching the data co presenting system to bridge a gap between, like, this fragmented and reactive environment to more something more connected. And it means that, for instance, if we take, like, a topic, such as animal detection that we we discuss a bit more later on, it will span from, like, your entire operation, like, across all of it with what what goes on is capturing the expertise of your engineers, bringing the institutional knowledge than just relying on people and their individual expertise. And when they leave, you you you got stuck. So it's really diff this is really this idea of moving from one line of production to something that scale across a plant and across your entire organization. So moving to, like, the next slide, we it's really, like, idea. Like, can we, in fact, capture the knowledge from your from your engineers? Can you capture that in in a platform? And even when when you retire, Can you maybe, like, identify, like, issues before they happen because this is sometimes some something that cost you and or at least understand the root cause more efficiently to reduce the time it takes to analyze what happened what was wrong. And, also, make sure that it's not only working for one one plant or one type of equipment or one type of vehicle, it but it works for all of them. So and whatever they are, whatever is the information you get, it you manage to scale it and make it work, across across your organization. So this is what we what we thought, as important for creating those presenting system. So to deep dive a a bit on what they are, let me introduce you, like, to the four type of, reasoning system that we see. So we we have identified talking with our with our customer and and with, like, our peers, that are really four four categories of, archetype, of reasoning system for industrial operation. The four of them are on the slide. So one which is more like about looking at asset reliability and retransitioning from this idea of reactive maintenance to proactive maintenance and using root cause analysis, and and we deep dive on this one later on on our session. The second one, which is really improving the process performance, so better quality between yield, again, with better monitoring and, and better wood. The third one, which is for for big equipment provider, like big, while, like, delivering, like, aftermarket, feed service, it's really using all the information that you have from stoppage of equipment, from your field, to really anticipate this issue and react as fast as possible, and don't get stuck for for ages. And then the last one, which is also quite important, is to try to to surface all the knowledge from from the design, from the development of your engineers, to get all these history that you have, all those background information that you have in your organization that's in your corporate relations. They may have like, you may have it for for decades, of information related to engineering, mechanical engineering, chemical formulation. You can think of of many here, how to get all those data together to really, like, so fast insight from from this history and and really, like, develop better better product, for for your company. So now that I've introduced those four, let's, have Henry, did dive into this production performance topic. Thanks, Peter. Yeah. So the first one, as Per mentioned, is around the topic of production performance. So, obviously, as we all know, this is a topic relevant for all industries regardless if you're coming from chemicals, Sweden bev, automotive, or semiconductors. We know every plant floor is really fighting to improve this to some extent or another. And, what we and our team, really observe again and again across customers and industries is that, often there's more than enough data already available, across many companies manufacturing processes. But the real challenge is contextualizing this data to make it usable to genetic systems to basically go from, noise and and a flood of data to insights that help you, actually make, impactful and valuable decisions in your processes. So for this, production performance, archetype, so we're dealing with, kind of classical structured process data mainly. So logs from your MES on your production and your products, for example, recipes and process parameters for continuous batch manufacturing, results from your, QA, QC, probably in your LIMS system. And, all this data is being then leveraged, by a reasoning system, for example, to help with, making decisions across your process. So there's kind of two main types of reasoning that we envision here. So, number one, about, having the system help give you recommendations to allow for improving your parameter settings for runs to either increase the yield or reduce the scrap. So here, the system does this by learning from historical production runs. So for example, identifying, like, the golden batch as the reference, also leveraging classical machine learning to derive correlations between your input settings and, for example, the process output to be able to basically make predictions on yield and quality, but to also use this to then help with the root cause analysis, when you don't actually meet the quality or the yield that you're targeting. And the second area is, basically, when your post is already running, help using the system to help get recommendations how to, intervene in a timely manner. So basically, monitoring the process for drift from your reference trajectories. Of course, this is possible without a reasoning system, you're probably already doing this in a form or another, maybe with SPC, for example. But, in the case of a reasoning system, it's not just basing this on static thresholds or tolerances. It's, also taking whatever current product is being produced into account. It's taking into account, the asset you're running it on, the process of parameters you've set, And all this is feeding into the system to then, help make these recommendations. And basically, in parallel, that's also leveraging the predictions from, the models you've built to model the process, as well as and this is very important, like business rules and logic. So for example, I don't know, for product a, if the mean quality, deviation is is 10% beyond what it's been in the last, three months, then there's something wrong. So really taking a multipronged, monitoring approach, And, this really isn't feasible with traditional systems. And this is really applicable to, processes where, like, a simple monitoring approach isn't efficient, where you need something more robust, more nuanced. For example, this is a, an application I'm talking about with several of our, pharma manufacturing, customers. So they're interested in, taking such an approach for their biological batch reactors to better improve the yield for these. So, ultimately, this one's really about, operational leverage. It's about empowering your operations teams to really maximize the yield and boost throughput, by using the data that's already there, to derive insights and provide decisions when it comes to, improving the production performance. I'll hand off for the next one. Hey. Alright. Aftermarket field service. So for those that are familiar with Dataiku, you know we're AI analytics, advanced analytics platform. For those that don't, we are an AI and advanced analytics platform. And one of the ways that our so we have, hundreds of large large customers, enterprises, right, that you would all be familiar with that use Dataiku today in both, as Henry had mentioned, pharmaceutical as well as we have a lot of OEMs. So think of an industrial equipment and machinery, aerospace, industries, as well as medical device, semi and electronics, otherwise, you know, high-tech type industries. Now a large part of of what they do, right, is some of those IoT initiatives around connected products. So presently, we have a lot of our customers that leverage our platform today to help support aftermarket, sales and service generally. That can mean a lot of different things. And so from a reasoning system perspective, where our customers are exploring a lot of different opportunities with us and where a lot of interest has been generated is around this whole domain of this area around aftermarket services support and sales. So that means what? It can mean a lot of different things. Right? So, everything from a warranty adjudication, which a lot of you on the automotive side may be familiar with. Right? But we also have that, obviously, that exists within your large OEMs that provide industrial equipment to manufacturers themselves. So things like validating the performance of products and helping to validate whether or not this was a utilization issue that a customer experienced or was in fact a manufacturing defect or a design issue. The other aspect of it is just in general, how do I improve things like my, competitive differentiation? And a big piece of that is how well are my products performing out there in the field. Right? And how are my customers utilizing them? That could feedback both into, helping with increasing things like NPS scores, so improving, brand recognition and product quality, and also tie that back into your design cycles, which Pierre is gonna talk a little bit about next. But what I wanted to just emphasize here is the reasoning system allows for quicker, understanding and diagnosis of those issues that are either reported by the customer or could be detected as a result of some telemetry data anomalies and other deterministic and nondeterministic rules. So when you think about what is a reasoning system and how is Dataiku addressing it, what we're really trying to solve here is the problem of context within all of these different systems that exist today and piecing all of that data together, connecting those digital threads, in this case, in the service of providing quicker root cause analysis of product quality issues to improve aftermarket service and also those aftermarket that profitable aftermarket sales business. But I'll let Pierre talk a little bit how we close that loop back with design. Yeah. Thanks thanks a lot, Christine. So now let's look at design development. And and as as it was mentioned, like, we we do have, like, customers across the board, from automotive to aerospace to chemical to pharma, life sciences, semiconductors. And all and all of those big customers, I mean, they differentiate themselves because they have they have been knowledge through the years. They have, like, decades of expertise. They have decade they have many, many engineers working as a design of the product for a chemical formulation. And and the key question to differentiate themselves is really, like, how to make sure that our best engineering knowledge is captured in our system. And when someone leave, when someone retire, like, we it can continue and we build upon it, and we don't restart from the beginning. So, really, here is the idea and question that we had more and more, like, through the the past year because of the of the increase of usage of agency KI. The the from our from our customer is that how I can get value from the past projects, the past simulations that I've done, for for make maybe, like, materials or even maybe, like, structural failures, as that as Devon and I from testing my equipment. And those information, they may be, like, available into different systems. So PLM system, CADFAX, and so you need to to go and look at those information. Those are a complex data. And when a new engineer start a project, sometime, not all the time, but sometime, it's it's a bit reinventing the wheel because you don't really know what has been done before. You don't really know what what was, like, really the best simulation, maybe the best, design. So you may want to re restart from something and and you're not sure. So really, here's the idea of this prisming system is to capture the domain expertise, to make sure it's persistent, to make sure, you you capture it in your corporate you capture all your corporate knowledge, and you're also able to really learn through time by having metrics from from those past simulation so don't so the team don't repeat the same the missing mistake. And and, of course, what we want to make sure it's this is a key aspect of the, like, who is that we want to make sure this is governed and and editable. So we make sure that all those design, all those simulations that you are running, you're able also to to make sure at the end that you have some kind of reporting, some guidelines that you are generating. So to make sure that you the the proof, that you need to provide for some safety compliance are validated at the end. So, ultimately, by connecting all those different type of data, PLM data, CAD files, engineering logs, we give to your scientists, to your engineers, chemical engineers, mechanical engineers, and your IT team an eligible sandbox, to design faster and safer, within data lake. So now, I'll let finish. Christine, on the on the last, topic we we want to deep dive today on. Yeah. So one of the key components of what you're gonna see in the demonstration that we'll do here in just a little bit is, how Dataiku how some of these approaches our reasoning system helps with equipment reliability and ensuring it. So, obviously, there are various ways that a lot of you are addressing reliability today, and it can mean different things depending upon the industry that you're in. So for those that are in process, you know, industries, highly capital intensive industries, you know, reliability center of maintenance through a combination of of existing CMMS and APM tools and software solutions and probably in play. For a lot of our customers, right, that maturity can vary. And when it comes to equipment reliability, one of the biggest challenges in term for a lot of the customers that we work with is understanding what matters. Right? And what I mean by that is there's a lot of noise within your, automation system data or your IoT data, whether that's aftermarket or whether it's at the shop floor. There's a lot of noise in that data. The the data in and of itself, that time series data lacks any context whatsoever. And if you take a lot of times, and this is traditionally been the case for many years. Right? If you take a purely data driven approach, and this is really where data IQ where at least how we see things. Right? If you take a purely data driven approach, a lot of times, what you're gonna find is you will have anomalies. Doesn't mean that those anomalies are indicative of a a a mechanical issue or some sort of process failure or upset. So being able to differentiate what the data is telling you versus, you know, what is all the context that's happening. Am I in a changeover state? What's happening in the shop floor? Am I actually am I even producing anything at this particular time? It's those kinds of pieces of information that allow you to go from just date purely data driven approaches to a combination of data and domain driven or for those that may be familiar with the term data and physics driven based modeling. And that's really the approach here that at least our customers find the most success with about addressing things like equipment reliability. And for everyone, particularly, you know, capital intensive industries, it's a huge cost advantage. Right? There's a there's, of course, a lot of risk associated with, asset reliability. In some cases, the cost of failure is huge. And in other cases, it's more of an issue of ensuring that you have the proper seamless flow and throughput within your organization and within your plants. So those are the kinds of things that we're able to achieve, and it uses a combination of in terms of inputs, again, I mentioned it, but your automation data, your so think of the telemetry data, right, coming off of the equipment, your process control systems, your historians, IoT, etcetera. That's new that's part of it from an anomaly detection standpoint. Then there's also to do it in a scalable way. You do this typically, and we'll talk about this in the demo, by asset class and looking at those different failure modes and effects. So you're using that information. You've got a lot of information already embedded within the domain experts and also right within some of your existing SOPs, o and m manuals, and documentation. So it's about combining all of those to effectively reduce some planned downtime and also, right, reduce unnecessary maintenance, which is a huge cost driver for a lot of organizations. And that's ex exactly what somebody was asking in the chat about some, we're I I think it was, around rival analysis and things like that and different reliability approaches. And that's exactly how some of our tooling is used for our customers. This helped to support some of those statistical analysis and ultimately, right, those machine learning approaches. Now we can go to the next. Yeah. And that is exactly, in terms of I think we kind of framed it, but just to give you an overview for everybody that that's here on this webinar, how Dataiku is what we essentially are from a a an architecture perspective is that, we do sit for those familiar with the ISA 95 stack. We do sit typically within that, level four, level five area, right, connecting to a lot of your traditional enterprise data warehouses and using that information that's already been, aggregated, if you will, or centralized within those data warehouses. We do have direct connectors to things like your level three systems such as your OSI PIs, your classical historians. But for the most part, Dataiku exists to help connect all of this enterprise data. Right? Because I mentioned the context earlier. So the granular data that you use to in indicate whether or not there's an operational reliability problem also needs to be enriched. Right? With that more, I would say enterprise data coming from your maintenance management systems or your ERP systems to know what you're producing and running. And that's typically where Dataiku does align within an organization. And what we exist to do is to help through that end to end analytics pipeline. Everything from how do I model something and then how do I, how do I orchestrate these analytics pipelines and workflows repeatedly. You know, in in the context of the reasoning system thank you. Yeah. No. You can go to the next one. That's exactly where I was going. In the context of the reasoning system, right, do you so you understand what does that mean. Right? We've kinda mentioned it. We've talked about, like, root cause analysis diagnosis of issues. We it's a way to connect all of those dots. Right? Everything from the data layer, data quality issues, which are rampant, systemic throughout all manufacturing, even the best, you know, even the most mature organizations to then what do I do with that information? So how do I model it? How do I represent it? That could be a data model, your ISA 95 type of data model, for example, but everything for to all the way to machine learning models for things like anomaly detection. And then agents are very that's, I think, been the newest paradigm or real, emphasis within all of industry, but I definitely see it a lot within manufacturing. And that is, using agentic workflows. Right? Combination of deterministic and nondeterministic approaches and rules to be able to dissect all of this information and derive a a root cause analysis of a particular issue and then recommend prescriptively. So go from predictive maintenance or preventative maintenance to predict predictive maintenance ultimately to prescriptive maintenance. And, really, agents do provide a great way to facilitate that because, remember, you're gonna have thousands of different asset classes within a typical manufacturing organization or even more than that. Right? And the reality is those failure modes effects are gonna be different. So that whole, that that diagnosis, right, and that decision tree and that workflow of defining what actually went wrong is gonna vary across different asset classes. So you need to have that agility, and that's really where agents come in and ultimately can provide that prescriptive recommendation so that some either engineer, maintenance tech, maintenance supervisor can take action and then basically translate and transform all of that data into a meaningful, actionable, corrective remediation. And I think next, Henry's gonna talk a little bit about what that could mean in another context. Thanks, Christine. Yep. So, just before we go into the demo, just to make, make it a bit more tangible, here we've outlined a bit kind of what we would imagine it before and after to be right going from a situation as Christine, was outlining, where you don't have this agentic reasoning to remediate an issue to then having one in place. So here we've taken the example of, chemical manufacturing. You have some kind of, batch, manufacturing where then, there's a gradual drift happening, over several weeks. And the question is, okay. Number one, do we, register it soon enough, or does it take a long time? Could we probably have a sea of data, lots of alerts, different tables, different metrics? So registering it, number one. And secondly, the challenge, and this is actually the bigger one, what Christine was going towards, identifying the root cause. And, as you see here, basically, the status quo approach is a pretty disjointed path to the resolution. Right? You have multiple people. You have a myriad of systems that you need to search through, to define the answers and to check your different hypotheses. And then, there's many different potential paths, potential root causes that that could be the case. And, basically, you're not sure if it's, I don't know, coming from, the assets. Yeah. So if you could stay on that page for a second, if, if it's coming from the assets, if it's because of the wrong process parameters, was the recipe setting wrong, what's something with input quality, that's causing the, in this case, the batches to take longer. Maybe even as Christine was saying, for some of the time, we had shutdowns and weren't even producing, and that was causing the durations to register as longer. And there's lots of possible explanations. And the typical path, someone would take to, determine this would be first gather data about each batch. Right? They probably need to be taking that from the story, and then you need to review, the different metrics, KPIs that you have for the batches to see if any of them are flagging an issue. You probably need to then pull more data from your MES, compare different batch performance. How do the slow ones compare to the fast ones? Were there quality issues that are somewhere hidden in the limbs for the slow batches or maybe even, it's because of certain suppliers. If it is because of the suppliers, you'll need to, identify which supplier lots that's related to, probably also do some kind of financial modeling on what the impact was for documentation purposes, and then finally escalate that to the category manager so they can then do some kind of audit with the suppliers. So, basically, the bottom line cost is gonna be throughput. So it's gonna, number one, possibly take longer to take the drift. In any case, it's gonna be going on longer because, either it's not detected fast enough, or more likely the resolution takes a while just because you have these different steps and and people that are dependent on. And secondly, you might not be fixing the actual root cause, but rather just firefighting, and trying to fix the cyst, symptoms really quick without actually addressing the core issue. And on the next page here, we've shown what that would then look like with the reasoning system in the ideal case. So as you see here, it's a much more streamlined process. And the ideal scenario, it's still the same steps that the agent is going through. But here, we're actually, able to automate a lot of this because, actually, I mean, if you think about it, the problem isn't that the, steps are overly complex. Although they are probably too nuanced for classical RPA, otherwise, it would have already been automated in the past. But it's just that the these steps are lengthy. There's disjointed, repetitive. They require waiting on people, finding in the right data, and, really, a genetic reasoning system, as Christine was saying, are perfect fit for this kind of, challenge that you're trying to address. So it's going through the same steps. These are probably defined in SOPs or or you can really define it in this system setup, what steps it needs to go through, and it's able to do this, basically autonomously. And, once you have the the agents in place and have the system in place, the agents, as you can see here, they can access different tools, for example, to do the detection, access SPC tools, through the root cause analysis, access to different data systems, and do the same checks, basically, the person was doing, but doing those, themselves because they actually have an understanding of the data. They have this context information, probably have semantic models that are giving them an understanding of the data means, which we'll show on the demo in a moment, and are then able to actually reason as we call these systems through what the actual root cause was b. This case, it's able to identify, okay, supplier b, who's providing the catalyst, all the lots from them seem to be, responsible for those little batches. And then at that point, then, the process engineer can step in, can double check the work perhaps, and then basically give the approval. Okay. Yes. This needs to be flagged and escalated to the category manager. And in the end, the bottom line here is that, it's, in the end, done much faster. So you're probably able to, reduce this drift much more quickly and resolve it. And, also, do this continuous improvement and so really be able to, have more time to focus on more complex root cause analysis where the injector system maybe can't do it because the system would probably flag root causes, analysis where it's not sure of the actual result. We really need, an engineer to actually dig through, the, things that could have gone wrong. And but, usually, they don't have time to focus on that because they're doing the regular root cause analysis on more simple tasks also. So that's really the benefit that we're getting here. But with that, I think, everyone's burning to see the demo, so I'll hand over to, Christine to lead us through the demo, first part. Okay. Yeah. Let me go ahead and, Nicola, is it okay if you share your screen? I'm just having a little bit of a Yeah. an issue. Sure. Yeah. Thank you so much. Yeah. And and so while we show the screen, if you have any question related to the presentation and also, like, to the demo, like, don't hesitate to to send them in the chat. We're happy to answer them. Awesome. Okay. So as a I mean, as a process engineer or as an engineering manager, right, what do I care about? Well, I care about knowing the health of my equipment and processes, and that's easier said than done in many cases. And as a result of that, right, that health can have it can mean many different things depending on what we're talking about. But one indication of it is how many alerts I have. Now what does that mean traditionally? You everybody has hard alarms coming off of the, you know, the their DCS or SCADA, whatever the case may be, or their PLCs themselves. That exists already today. That's rampant throughout organizations. But that kind of unit variant deterministic monitoring doesn't always reflect, right, the true health of a process or an asset. And that's precisely why I want to have something like an overall more holistic view. So what I can see here at a glance is that and and traditionally, I may just rely on some of those post hoc reports, but and I would have dashboards as well, but I don't necessarily have that good representation of the true health of my processes and equipment. And that's why I'm planning downtime and unexpected quality issues still happen within organizations. So if we go through here and yeah. I apologize. I had that issue. But if we go through here to the overview, Nicola, if you could click there for a second if you don't mind. Thank you. So what I can see from that first screen is I have the information on number of alerts and also the kind of savings. Like, that's an important piece of it as well, understanding what am I doing and how much am I able to defer and avoid some costs that I've traditionally had to incur for unplanned maintenance or for other unexpected shutdowns, for example. In this case, now I can drill in a little bit more deeply to understand what are the nature of the problems occurring. So I have a factory. I have many different lines and pieces of equipment on that line. And here I can see these alerts prioritized, reactor six versus dispersion line seven. So that prioritization is important because you're gonna be inundated, right, with alarms. How do I understand what is actually important? What do I need to focus on? What deserves my utmost attention? And that's what we're we're seeing here. If I drill in to get more details on what's happening, what I can start to see is that I can get those, more more fleshed out details on what actually is happening within this reactor. So what the agent has done here behind the scenes now as a process engineer before, what I would have to do is go through and probably look at the historian data, do an exhaustive analysis in maybe PI Vision, etcetera. Then I would also look at my MES or my production summary data to figure out what I was running and, what was you know, when did it start, when did it stop, really start to combine some of those. If I'm really good, maybe I have some event frames so I don't have to do too much of that joining of data, but I'm still gonna have to drill in and understand what were all of those different, parameters or those variables and sensors, essentially, that were associated with this issue. Here, what I have is all of that's already, aggregated and presented for me and consolidated in a way that now I can go from what would have taken probably an all time, you know, sometimes these can take days to do this root cause analysis. And so you're not gonna do it all the time. Right? It's very ad hoc and only when it's a kind of an ongoing problem. In this case, this affords me the ability to look at all of these different issues and then understand pretty quickly what is the root cause. In this case, what we have is a cooling system failure. Right? So essentially, I'm fouling in my heat exchanger. And heat exchanger fouling is causing this excessive temperature and a runaway action a runaway reaction that prompts us to have to shut down prematurely. This results in lost production. It results results in downtime and, excessive amount of waste. So as a now as an engineer, I understand and I can go through. Right? This is the nice thing. It's not just the agent gives me the answer, but I know the lineage of how it got to that answer and what is, what is the data around which it is, using to derive this explanation. Then I can go even further and take action on it. So that means doing things like, I I can go ahead and qualify this alert. I can escalate it. Really important point here is I can also void it. So, for example, it says it's a, in this case, we have a heat exchanger filing issue, but perhaps maybe we were doing a test run or, we were doing some sort of, other maintenance burn in type of activity. In that kind of case, what I want is my injected workflows and my root cause analysis and diagnoses to get better over time. Right? That how are they gonna get better? Well, they're gonna get better from my input and understanding exactly what went in to all of this and then for even providing information about why this is not a valid alert. So, again, it's not just about what I'm what I'm presented with today, but being able to interact with these agents to make them better in the future. And, also, like I mentioned earlier, it's how do I take data and transform it into actionable remediation and fixes for an issue. So with that, the other piece of this that is really critical and is that I need to be able to answer these questions myself. Right? I can't just rely on something like IT to always spin this up for me. We have, like, we could have, you know, many multiple lines right in a particular shop floor. I'm gonna have hundreds of assets. So how do I answer these questions myself? Right? And also, how do I even trust the agent? I have to be involved in that whole construction process. So that means that I need to understand what went into all of this analysis. In this case, I can have an overview here of everything that's happening within that plant and all of the relationships. Right? To understand, for example, that I have a heat exchanger filing issue, I the this the, agent needs access to understanding my overall process flow. So it knows which assets to look at in which kind of parameters, and we're not looking for a needle in a haystack here. It has to have some of that definition. So that's part of where I can I am I can have trust in the result that I'm provided? The other thing is if we have a heat exchanger fouling issue, most likely, right, at least we have a water treatment issue. In most cases, water side fouling. So if that's the case, what I might wanna do here is, you know what? I think we have a bigger problem. We need to spin up a new model, and we need to extend this this, current reasoning system to include additional data inputs that it doesn't have access to today. And that's again how we can continuously improve what we have today so that it is better and more representative tomorrow. So if I go ahead and add a new model here, then what I can see is that I will have things like the ability to define what data do I need to access, what does what do I want the agent to access. So behind the scenes, we have things like agents that are helping with all the data preparation here. So profiling for what I care about is I need asset ID and I need time stamps. I know that that's important if I wanna move the needle on anything like OEE. So I can go ahead and accept that. Then I can attach different things, different information, knowledge bases from documents like o and m manuals or technical documentation. I can upload documents. I can just attach them via SharePoint. And then what that means is I already like I said, we were talking about context. You have context in your organization. You have it in the process engineer's head. Right? I have some that I know if I know this process, I'll understand that I care about, you know, five or six, you know, variables are most impactful. I also have it in documentation and I have it in these things called semantic models which helps me define exactly what it means. For example, the maintenance or inventory information, So making sure that my internal vernacular is translated into a way that the agent can understand it so it derives more meaningful and actionable results. And then we'll go through then the next step, I can go through and create KPIs and metrics. After that, I can go ahead. I can either define those externally or use them myself. I can attach those to the system. Again, I'm defining essentially, I'm building a machine learning model in the end that I just may not know that I'm doing it. Then I have agents helping me with preparation of data. Things like you don't need this column, there's it's too empty. Then there's business rules, pH should only between be between, you know, zero and fourteen, for example. So being able to represent all of that, those business rules and those deterministic, rules within your organization and use those as well because they're still very valid. Right? And you could keep your machine learning and your agentic workflows in line. And then from there, we could go ahead and add additional logic that's very specific to manufacturing such as Nelson rules. Right? So that kind of so those SPC statistical legacy SPC rules, so I have I have now data that's clean. Right? It's higher quality because I've been able to establish those, those boundaries and those thresholds. And then I have things like these SPC, you know, or Western Electric rules for those that know it that have been in the you know, around for decades. So all of that as a process engineer, I'm very familiar with. So that's nice too because, traditionally, when people just give me the output of a machine learning model, I don't necessarily know how that equates or relates to some of the statistical, univariate analysis I do today. And sometimes for simple assets, this is really sufficient, and we have a lot of of our customers that just use Dataiku for at scale very, I would say more traditional monitoring, but to be able to do it at scale is the real challenge across tens of thousands of assets. And then next, we're gonna move forward, and this is where that I I think, Nikola, I'm gonna kinda position to you. But, yeah, I wanna do things like I mentioned, you know, lots of anomalies that don't have any value. Well, here's where you can step back from that and look at, time series trends, which every process engineer cares about and most in engineering care about, And then go ahead and actually label those areas that for example, I know that looks a little funny. It looks like we have a sensor drift issue. And so, therefore, I don't wanna include that. Right? I don't want that to be a, or I might wanna include it, right, because I wanna get alerted to Sensor Drift. But I also may wanna exclude that from something like an anomaly detection model because I know, wow, that's that's not correct. So it's being able to take the, again, the context that I already have as a domain expert on a process and being able to translate that and harness that in a way that it becomes part of that analytics pipeline. Then after we would create those models, and we have customers that do this kind of thing today where they're labeling these trends, and they're using it for either fingerprinting processes or creating, more reliable fingerprints. And then finally, we could go ahead then I can if I'm happy with everything, I'll go ahead and deploy this. We'll train a model, and that's the basis on which now I could, have a more enriched and a wider view of what is happening within my plant shop floor, what's happening within my equipment so that I can have greater actionability and control over, right, visibility into everything that I know is important for my job and for our production operations. What's also nice is then I can get help from somebody like Nicola who's a data scientist. Yeah. So, basically, I have, I hope, Christine. I was able to follow along with what you you were saying correctly. But, so we've seen basically the the process to, to create a new model, and we've seen that anyone can actually do it. And then at each step, like, train or validate, you get an AI assisted type of results. So, basically, what you need is business expertise to actually create, those models and then, draw insight from what you're seeing on those overviews, tabs that Christine was, showing to you. But if you need a bit more control over the whole, solution and and if you need to understand what's going on, under the hood, then you can have access. You can give access to a second type of of persona, which would be more like me, a data scientist, and show what we call the reasoning section because this is meant to be a reasoning, a reasoning system. Right? It's not only an anomaly detection solution. It's something that builds on top, as a decision layer in the slide that we we just, showed you. So as a decision layer on top of all those artifacts that you can find in, in DSS core capabilities. So agents, machine learning models. Nothing of that is is kind of new. What we are trying to propose is to to predict what will be the next step and the next step to the to us is this reasoning, system which acts as the, the decision layer on top of all those, artifact. So what we have and what you could get, dreams of, when you, you try to open and understand what happened for a given anomaly is that several agents were, collaborating and coordinated by one agent. So under the hood, what you get is an architecture of agents that, is tailored to your specific needs because those reasoning systems, when we deploy them with clients, we have this initial phase where we tailor them exactly to your business processes. So for this specific example, we felt that we needed some, four dedicated agents, one scheduler, one maintenance agent, one old cause analyzer, and one monitoring agent with a coordinator that that acts upon, the decision of those agent. Because it's our experience that for to get the best result from those agents, you don't have to to rely on a single agent. It's better to to have a dedicated and specific agent for each, subtask that you can identify. You you need to, you know, divide and conquer, if I can, if I can use the expression. But you when you send the maintenance agent would have access to the semantic model dedicated to the maintenance table that you can find in that iQ. Semantic models are in that iQ, and you can use them, separately from from this reasoning system. But what this agent would do is is train to to to he has the right prompt and the right tool to actually leverage this semantic model and query the data for you, but he specialized, for this task. And so you have this whole architecture working for you that you can monitor from this reasoning section. In a sense, you can have a look at specific agent and know exactly what's, what's happening in terms of, specific API we use for agents. You can, you can edit the prompt if you want. You can have a look at the tools, the task he's currently doing. So he's scoring a lot of things at the moment, and you can even chat with with it if you want to have a better sense of, how he's behaving. And we can see that for some of those agents, we get some useful indicators that, comes exactly from the nature of the reasoning system. It's very hard to have control and to see how well an agent is behaving, and that's what we are trying to provide here with an indicator that we call human recall with qualification. Because at each step, when an agent proposed to you some, qualification, that you you have seen, in the in the areas, for instance, This one has been has been qualified as repair. I can decide that, actually, it's not entirely correct from the agent to qualify that repair, so I'm gonna qualify it as rework. And this is, this is, registered as an indicator for how well the agent is performing because, obviously, we want the agent to get it right the first time immediately without human requalification. Right? So if we if we get a sense that this agent needs more and more review, then there is something maybe that needs review from us in order to improve his performance. So what we are providing here is, like, this layer that it, that enables you to have control and, and, I know the trail of everything that's happening so you can catch, you know, a model and an agent drifting before it it impacts, the performance of the whole system. And then to be the same thing with, machine learning models in in more classical sense of way, and you you you can have access to all the elements used, tools, jobs that I said, knowledge based, and semantic models. And, maybe I'll conclude it here by saying that the distribution system add an additional layer of of memory, meaning that, the the all those agents have access to all the qualification you've done in the past, all the decision you've made by seeing a specific, alert. For instance, React or Sys, we we decided that it was a regrade. For instance, let's let's qualify that as as a regrade. All the agent know now that this is the decision you've made recently. So the old idea of the reasoning system is is that it has memory and then, an incremental understanding of what you're doing. So it's it's really reasoning. And the more you use it, the better it gets, basically. Maybe I'll stop here because we are a bit overtime. So thanks thanks a lot, for the demonstration and thanks a lot for the presentation. So we so we have shared with you, like, our vision. We have shared with you, like, how it looks in practice, to bridge this, like, connect data, model, and agents, and humans are loop. And as and Nicole was mentioning, like, keeping this memory, and enhancing this memory through time. So we now, like, have, five more minutes, to open the floor for question for you. I see that we start to have some more questions, so, happy to answer them. So I will start maybe with the with the first one. From so there's one which is, this agent, like, system are really dependent on the data that lies underneath it. How do you guys work with clients to make sure the data has all been consolidated and is available for this agent? Anyone wanna take the question? I think we we kind of answered the question, in this, in one of. the slide where we where we presented the the positioning of the Daikou. So we had a slide pushing Daikou over the ecosystem of, of a company. So we connect, to the different, cloud data platform, on premise data, and then providers and also enterprise application. So we are not replacing them. We are really connected on top, and and we are really benefiting what what has been done. So we can help, of course, to prepare it, clean it, contextualize the data, to make sure that the good data because we know that for agency and for machine learning, we need to have good data. So good data is available for people then to build, relevant application. I don't know if you wanna deep dive a bit more like, Nicola, on on this technical question. Yeah. I. think there's take ahead, Nicola. no. No. Go ahead. Go ahead, Christine. Oh, I was just gonna say there's the the technical answer, which I think you can provide very well in terms of different data science techniques to help with, I would say, data quality and also the automation of consolidating them. But I think that is also kind of a a a services and deployment question if I I'm not sure that that was the meaning necessarily. But in other words, hey. We have our, you know, data within air gap systems today. So how are you, as DataIQ, going to be able to access that, readily or easily? And we do have different ways that we work with customers in that kind of in those environments, to help facilitate that. Sometimes as our services team gets involved, we just create these reusable workflows. But that is is potentially so I think there's two ways to look at it from a deployment services perspective. And then, so we have we and then the then the data science side. Yeah. I just wanted to add that, basically, we don't have much time to demo the data to core capability, but that would have been a a great demo to show how well it integrates with what we have shown to you guys because the whole data preparation part and consolidation of data and connection to external systems and, and safety provided by the platform such as, you know, authentication, authorization. This is the bread and butter of the more traditional part of DSS. Right? So, basically, it's what it does both, and we are building on top of it to, you know, do the last kilometer of, you know, help you in your actual business process. But the whole all the data engineering part and data science part is covered by Dataiku and has been for more than thirteen years, yeah, now. Do we do we have, any other any other question on the chat? I'm checking. So maybe I I think there was a there was a question, I think, in the chat that I see. Yeah. And and I see analysis. I think I think take this one. this it's not anything that's been answered, but, yeah, you can provide more detail, Nicola, maybe. Yeah. To provide a more generic answer, if you need tailor metrics, then that's, that's that that's what the the semantic model is for. So semantic model in Dataiku is just a way to provide meaning to existing tables, and then you can define, metrics and golden queries. Meaning that if BPR can be written as a metric, then it's perfect. You can write it directly. And if it can be written using SQL so if you need a custom metric that can be written using SQL, you can by using that, I could type in some natural, natural language and then create the metrics for you. You can do it in that I could and you can do it, in the reasoning system. Me, interestingly, we do not have time to show it, but in in the screen where we had the the metrics, the last part was custom metrics. And you you can type in exactly what you want. And, obviously, it's a pretty good model. So if you type in DPR, you will find a way to write it in SQL so it works. And if you have additional documentation about the the custom metrics you wish to, to implement, then you can add the documentation into the reasoning system, and then the agent will, you know, do a search into the documentation, especially if you tell him to do so and then create the custom metric for you at that step. So that's one of the strengths of those models. Those are language models, so they are really good at translating language. So if you have documentation or if you know, custom metrics into an an actionable metric at the metric step of, of the application. Yes, sir. Nicola. Yes. I see that the question related to the presentation, it will be available. The recording will be available as the slide. There was a question also related to, other resuming system only available to that echo current customer. That's indeed, that's indeed true. We, we are working with, like, this is something that we we are providing and working with our customer. So this is we haven't talked about the approach. We take it to build it, but, really, as you have seen, we are really tackling, like, key processes. So the four processes that we, we presented initially. And for those four processes, we are working with the customer to understand what are the what are the key the key pain today, what are what kind of data they have, of course, what how they want to transform the process, that we have explained, like, for for one of them, for instance, and how let's see. Today and how it should be tomorrow. And working with them, we we build, similar reasoning system that was presented in the demo today. There's, also a couple questions on, both why scaling so hard. Sorry. I just saw some of these as the way it comes in the chat. And then also, how do we sit on top of their existing, like, MES, Historian, you know, classic ISA 95 kind of architecture stack, without a two year integration project. So, I mean, most of our customers, right, have those different capabilities today. And what they're doing within Dataiku is we didn't show you the core capability of the product necessarily. What we're showing you is that application sits on top and lets you leverage it. But that ETL work, as I'll refer to it a little bit last mile ETL, that is really bread and butter of what we do in terms of combining things like MES and historian data, being able to do that in a very drag and drop, kind of a SCADA like fashion. So think of it that way from a low code perspective. So that's pretty core to to, Dataiku capabilities. And then the the scaling issue is really, I think, yeah, that's a it's a very, very good point. The reason things don't scale traditionally is that if you do purely code driven approaches and, I mean, I've seen this on the IoT, you know, since when IoT started, but, yeah, everybody was talking about it in 2016. But, when you do those code heavy approaches, it's very, very difficult because you have to then redo everything. Right? Because you're gonna go to a different POC or different, you know, automation layer, and there's different failure modes. So if you think about it, like, for those that have MES, it's the same sort of approach there. Everything is different when you go to one line to another. But that framework of defining what is that equipment model, that framework of how do what what are those triggers, right, that indicate failure, that's kind of the approach. So you start from a scale perspective with that the same kind of operational theory. You start with a class of assets. And then from there, with that framework that I showed you, right, you're not what you're relying on is data that you have, so documentation and those existing, like, the time series data, for example, would be good at how that works. So but you're you're looking at and that's the nice thing about the agents that they can adapt to kind of those different approaches and those different, datasets, and they can flex a little bit more easily than traditionally in the the, what I would say, more code heavy approaches, which is a limitation. There's maybe one one last question. I see that was related to the building trust with operators. So are are the operators actually bid trust in a recommendation that they didn't generate themselves, especially on a critical line? Maybe maybe, Nicola, you want you want to talk about that, like, on on the fact that you can have the agent that is manager or or more manual. Yeah. Exactly. The the first the first bridge we have about that is the labeling part that Christina has shown you. So, yeah, this is really to inject your knowledge of what an anomaly is so you don't get this, you know, unsupervised type of, method that doesn't need you, in the loop to define what an anomaly is. So, basically, it's just learning from what you are inputting as this labeling, phase. And then you get, you know, the metrics, demoed quickly about monitoring our way it performs, when you will qualify the agent and when for the machine learning model. I didn't have time to go into detail, but you get with you know, you can add new data, read about it, and then see how well the the the existing model performs. And if there is some drift, meaning that, you know, new week, you noticed a couple of anomalies, you label them, did the model manage to, to, to detect them or not? This is an indicator you want to monitor over time. And, and so in terms of trust, that's you know, that gives you control, and then that gives you, auditability, meaning that's every all those decisions, you get an audit trail of everything the agent, told you the the the the all the qualification you did, so you can learn from, you know, past performance, improve, and have a trail of everything, you've done to, you know, to foster trust, in, using this reasoning system. So so I think we we are at the end of of the session. I think we we we have we have no not any more any questions. So thanks again for joining. I think there were many, many attending, still many attending, at the end of the session, and we have a bit of a overrun. So thanks again for joining. Again, as stated, the webinar will be available online. You can access it. You would access to the slide, and feel free to to reach out to us. If you have any more, specific question, we'll be happy to answer them. So thanks thanks a lot everyone for joining, and thanks to the team for for presenting today this, this great work on the reasoning system. Thank you. Have a good day. Bye bye.