 All right, everybody. Welcome back to another OpenShift Commons briefing. We'll be live streaming multiple channels on Twitch, Facebook, and YouTube, and we'll collect your questions from there. Today, we have a new hopefully Commons member, KPMG, joining us to give us a talk on their Ignite platform for... Well, we'll find out what it's all for. It's machine learning, data science, all kinds of good stuff. But we have Kevin Martelli and Hongfei Cao, who I'll let introduce themselves in more depth and talk a little bit about the Ignite platform and how they're running in an OpenShift. And then we'll have a technical demo and live Q&A, as always, at the end of this. So please, Kevin and Hongfei, take it away. Great. Thank you so much, and thanks everyone for taking the time out to go through this presentation. Quickly, before we dive into the details, I want to quickly introduce myself. So my name is Kevin Martelli. I'm a principal software engineer at KPMG, overseeing our big data software engineering team. A lot of stuff related to cloud containerizations and end-to-end deployments with machine learning. With me, I also have a colleague, Hongfei Cao. Hongfei, maybe a quick introduction on yourself. Yes, hello, Ron. My name is Hongfei Cao. I'm a big data engineer director from Red House KPMG. My specialty is on the big data analytics, distributed machine learning deployment as far as cloud computing. Great. Thank you, Hongfei. So, as was mentioned, we're going to give you a little bit of a background around the motivation that we had on building what we call KPMG Ignite, which is our data science platform and ecosystem to bring use cases from POCs into production. We'll drill a little bit into what Ignite is, so the audience can get a feel for what we're dealing with Ignite, how it works on top of OpenShift, and ultimately how it chooses to produce business value. And then finally, we'll go into some architectural components of it. And then I think the last part here on number four, which is the demonstration. And what we hope to do is through all the different parts that we'll take out, we'll walk through a very detailed technical demonstration. The demonstration will be representative of how the business can interact with it, how data scientists can interact with the platform, as well as how engineers can interact with the platform, and how we can productionalize these pipelines on top of OpenShift within containers. So, looking forward to this, and again, any questions, please feel free to type them in as we go. So, the first question that many of you may ask is why do we decide to build and invest so heavily into this platform that we use for our internal data science as well as client initiatives? And probably like many of you could guess, one of the main drivers was just the explosion, if you will, of AI in the marketplace. Many clients looking at it, to leveraging it, how can they use it. And we saw that there's a need there to kind of bring some of these technologies together. And not only from the standpoint of being able to, I would say, productionalize use cases, we do see a lot of people that are able to build cool POCs, but they're not always necessarily able to get them into a productionalized format. So, one of the things within our online platform is how can we come and bring these capabilities from both the POC to realize production, in addition, making sure we have those right hooks. So, how does the business interact with the platform and our scientists and engineers? And again, we'll drill a little bit into that detail. But as we looked at that, there's really about five or so areas that we see that enterprises need to be aggressive in in order to support AI and be able to bring AI more seamlessly into the organization. Some of these areas we do cover by Ignite, and then some of these areas have to be augmented with separate business processes. One of the important things here on number one is around data literacy and building up your data expertise. And we used to think about this more along the lines of something that an engineer or a scientist, a business analyst would do, but this is more holistically now across the organization. How do business folks understand their data? Can they get the right training data? Do they have access to the right data? Within Ignite, you'll learn we have different ways that this could be achieved. We have user interfaces. We have, you know, data sets from the technical side, which we'll talk through a little bit. The next is around technology. And I think we can all kind of agree that there's been a technology explosion in the space. Every day you wake up, there's new technologies available to produce, you know, similar types of outputs. And what technology should you use? What technology shouldn't you use? Where do you want to do your R&D investing around? One of the things we took for Ignite is that we realized that this market was going to be expanding so quickly. So we needed a very open ecosystem. Microservices, containerization, easy to plug in and plug out as these new AI tools and capabilities came to the marketplace. And that's something that we'll show you, too, within this demonstration. Business processes. How do business processes now change? How are people relying on the data from data science? How are people embedding this into their day-to-day, you know, work activities? How are the enterprises adopting this? And then the workforce. It's important that we enhance some of our legacy skill sets. We hire new folks and how does our workforce support this? How do we move from sort of the legacy monolithic into these more agile, you know, quick developing and productionization of machine learning pipelines? And then the final part I'll just briefly touch on is around risk and reputation. I think we all know that there could be a lot of risk associated to some of this. The importance of, you know, understanding your model, understanding the details that are going into your model. How are you managing this? We see a lot of organizations, you know, coming out with ways that they can have explainability and making sure that their models are fixed of bias and how do you fix these things. So there's new risk and reputational risk that organizations are facing in this era. And again, these are some of the capabilities we hope that we can help support through the deployment of our KPMG Ignite platform. So with that, I'll jump down to, you know, what is KPMG Ignite? And we touched a little bit on these topics earlier, but essentially we have the who, the what, and the why. From the who, who is this platform built for? Who were you having in mind that could use it? It was a platform predominantly built for our data science and data engineers so they could build the pipelines. However, you know, without having the business and the ability for others, analysts, et cetera, to be able to put input into the system, it just wasn't necessarily as, I would say, useful. So there's business hook. So whether that comes from annotating and creating trading data, whether that comes from value dating model results, there's different areas where the business and business analysts can come in to work within the platform. The what part. So what is it? And we talked a little bit before. This is a global AI platform. We have a very modular slash micro service type of delivery. So each module and we'll dive into that could be an OCR job. A module can be a model. A module can be a data extraction. So we'll jump into some of these things, what these models are, but they're built in such a way that they're sort of interchangeable. So if there's a new capability in the marketplace that comes out and we want to take advantage of it, you can plug it into the platform seamlessly and as capabilities deprecate, they could be removed from the platform. Then finally, the why. What we noticed is that, you know, as we mentioned before, there was a high demand for these types of capabilities, but more importantly, as organizations sort of took their journey into the AI space and unstructured data and semi-structured, there was a lot of work around unstructured data sets. So loan documents or contract documents, PDF documents, how could organizations get the right information out of them, voice documents, et cetera, and make the correct business decision. So this was really the why of this platform and why it was built sort of with an unstructured data set in mind. Again, going back to sort of the prior point, this was a platform that was built for data scientists as well as data engineers with those business folks. And as we mentioned, it's very important that the business had a way to integrate into the platform to provide the right data sets, both from a training perspective as well as a data validation perspective, back into the process to making sure that we were building the right models, deploying the right models, and kind of meeting the business requirements and expectations. And then the modular component architecture. This is, I would say, the crux of what we built our platform on. We're really building it on the foundation of very small capabilities and services that could be interchanged with other services so you can string together a pipeline to produce some type of output. For example, maybe a pipeline is you need to OCR a PDF document. You then need to break down that PDF document so you can start making business decisions. So maybe you add some, you know, spacey into it to enhance it, or you might do some sectioning of the document, and then ultimately you might make some type of business decision on it. All these different components are modular and kind of executed by themselves, or you can call different components that may reside in different cloud providers, whether that's, you know, GCP, AWS, or Azure. Another area was that it was, you could be deployed via containers, or it supports RESTful services into the platform based on the demand that you need to push through. And then finally, it's around reusability. So all these components are reusable. So if one person creates a component in the community and that component has the capability of doing something, that component gets checked in, can be re-leveraged, and then rebuilt into an image and ultimately brought back into the platform. And again, some of this might be a little confusing through the talk, but once we drill into the demonstration, I think it will become a little bit more real. And then finally, you know, it unlocks the value of unstructured data with surgical precision. So one of the things that we really want to do is be able to get out that content in documents that are able to help the business make decisions. And many times you'll have hundreds of pages of documents, but there's only certain sections or clauses or dates or information that the business needs to be able to make that business decision. And how do you get that information out? And that's all part about this pipeline that can be built on top of the platform about how this, I call it, the documents become mature and more and more enriched so you can start extrapolating out the right information to then be able to make the right business decisions. So as I was mentioning, Ignite is really made up of many different layers as you see here. And what I guess I want to talk about is what I call sort of the foundational pieces that make Ignite Ignite. And we really break it down into these five buckets. So a loom is really the main mechanism of how Ignite communicates from one component to another. And it's a proprietary data type or data element that we use here. But what it does is it allows for one component to receive data in and push data out in a consistent way. And a loom is really nothing more than an enhanced JSON. The next is we have our data science notebooks, which many of you are probably familiar with. Within the data science notebooks, you have the ability to read your own pipelines and workflows to test them, to build them and to deploy them. The data science notebook themselves, it's done through Jupyter Hub and then each user will get sort of their individual notebook. And then we talked about a little bit around how the business and users can get in there. And we have two main mechanisms. We have the annotation UI, which Hanke is going to be able to go through in our demonstration, which I think is pretty powerful, how business users can then annotate documents. And those annotations are ultimately fed in to feed the models. And then there's some management UIs as well. And these are areas where you can build workflows and string things together in a more user-friendly way versus building it out through different code bases. And then finally, one of the things I think which is a gap in some of the other areas that we deal with is around model management. And the ability to manage your model, understanding the statistics associated to your model, many times feeding into your model governance process, as well as serving up models. And I guess one of the things I want to show on this slide is if we sort of understand the platform, I want to walk through from the bottom, from the pools of persistent volumes up through kind of the application layer just to give you a feel for how the platform itself works. So at the bottom, we have persistent volumes for our OpenShift cluster that are attached into the cluster. And if you move one layer, we have our core infrastructure. So what we use is we use Distributed MinIO to facilitate object storage, which gives us better latency, faster read and write times. We also have a Postgres database that stores a lot of the metadata associated to the processing and the workflows. We have our logging and reporting within Kibana and Elasticsearch. We use Kafka as our message broker. But Kafka is really set up in a way that allows you to, why do you execute one component to the next component? Kafka is a way that keeps the queue for the next component to pick up. And then finally, everything's executed across the container organization platform and orchestration through OpenShift. I will take from there. As Kevin mentioned, the whole in-night platform is designed for data science and data engineers to build arbitrary machine learning pipeline and also easily collaborate for different business use cases. So in this architecture, as Kevin covers, there's a volume core infrastructure. On top of the core infrastructure, we have our macro services for each infrastructure component. We deploy it in a secure OpenShift environment and expose it as API for a user to access. And on top of the infrastructure, we have our machine learning pipeline component. You can see we have some pre-built models like Ignite OCR, Test-Write Model, NLP Spacey, Machine Learning, Model Manager, Model Deployer, and Intelligent Domain Engine. So those will be its own macro services, has its own Docker image, and it will deploy it as its own part. Later in one of the demo I'm going to show you later, you can see how we create and customize each machine learning component and execute it using Ignite Platform OpenShift. So moving on to the next page. So here is another view. I got to show you the high-level architecture about Ignite Platform and how we deployed OpenShift. After that, I will show you the actual deployment using our secure OpenShift. So as we mentioned, the whole deployment is container-based and it can plug in different shipwrecks to cloud infrastructure OpenShift or on-prime VM or on-prime private cloud. And we deployed the whole plan from using the CSAD pipeline. So the CSAD panel can help us set up a secret config map and all the infrastructure component deployment including Kafka, the API, the LED search, the AFK, et cetera. And once we have the infrastructure component deployed there, we can use the Drupal Notebook as our data science platform to customize and build any like this arbitrary machine learning pipeline or workflow using the predefined component or Docker image. Here we show once the workflow we built using this Ignite Platform, it starts from the raw PDF scan PDF and we can, you know, to draw in the test write, generate the OCR raw text data, and we can do some sectioning to segregate different text write into each section and run some NLP processing through the Python Space Library. And we have our Ignite customized component called Intelligent Managing to extract certain interest fields, such as contract number, contract borrower name, et cetera. At the end, we have 100 written detection components. The whole model is also, the machine learning model is also deployed and version controlled using MLflow. For those who are not familiar with MLflow, it is an open source project, which offers version control and decentralized storage for any machine learning model. We support the Python Secular model, as well as Spark ML model in packet format, TensorFlow, right-watch model, et cetera. So we are leveraging the MLflow as our model storage, and we have our building component called a model deployer for the deployment. So without any questions so far? All right. I think we can move on to the demo. So for the rest of time, I have three demos for you. The first one is I'm going to show you how we deploy the Ignite platform to a secured OpenShift platform. And then, followed on that, I will show you how to leverage Ignite platform on OpenShift to do the annotation and using MLflow to manage the complete lifecycle of machine learning model. In StarFonds data preparation, how we can use our annotation UI to prepare the training data, testing data to generate the label for our supervised learning model. And all the way to the model prediction classification, and we have interface application tools for you for any user to correct the model output. And as a last demo, I will show you how to use a Jupyter notebook to customize and create an arbitrary machine learning workflow pipeline using the predefined Ignite component. For example, the Spacey, Tesserite, OCR, and IDE. Without further ado, let me jump to the first demo. So as you can see, we are deploying the whole Ignite platform into this secured OpenShift platform. And let me quickly jump to the components we deployed. As I mentioned earlier, we are using the CSED pipeline to help us deploy all the infrastructure component for Ignite platform and also set up services routes for any API or web application exposed to the end user. Also, the CSED pipeline will help us customize and configure service accounts, the map, and make sure the security is placed properly. As you can see, we have several posts, the whole Ignite platform deployed there. So you'll see multiple posts running at this point. And for the data scientist or data engineer, we have the Jupyter notebook for them to test or develop a new machine learning pipeline. You can see each data scientist or engineer and the user, when they log into our Jupyter app notebook, they will create their own pod. So they have a segregated environment for them to test and develop. So they don't need to worry about access control or other users, right? Externally change where we move their code. Okay, so whole Ignite platform. Okay, Hanfei, can you go to IQ first? Sure, it's IQ, yes. All right, so let's quickly jump to the Ignite IQ demo, and then we can come by to the detailed Ignite platform deployment ownership. So here is the tools for data scientists and the data engineer managed machine learning model. The second is we are using MLflow to store and version control in this training model. It actually includes the whole serialized binary of your model. So these tools basically help you selecting the model store. So you can use these tools to check and reveal all the existing models in MLflow. So you can manage and create a new model through this web application. Here I'm going to show you, I already logged in as admin. That can look at it in this Ignite model workspace. We already have three models created. And also let me jump in one model here. So this model is called start date. So what happened is we were processing a bunch of financial services contract documents, and the model will automatically extract the content from the raw PDF to get the start date for this contract. And we don't have rely on any predefined template. This is purely MLP and machine learning model. So the first thing you want to do is you want to create the model using this Ignite IQ admin tool by giving the model name. What's the status of this model? The first status is always the setup, meaning you give the model name, you set up the target accuracy you want to reach for the model. And you start preparing the training and the testing data side. So at that point we are moving to the annotation stage. Once the training data, testing data set is ready, we'll move on to the modeling stage, which will train the model and validate the model using the testing data set. At the end, we have a holdout data set for you to really validate and test your model without the actual true ground truth label. And at this stage, we have the user interface. For any user, they can go to the model result and manually correct or accept the model result. As the last stage is complete. So when we save the model in using this admin tools, what happens is in the backhand, the MLflow, it will create an entry project in the MLflow for this model. Let me quickly show you here. This is the backhand MLflow engine. As I mentioned earlier, this is used as our centralized model storage and model database. It provides version control and also some type of a model serving. But for the actual ignited workflow, we have our own model serving component model deployer. And Hanfei, maybe one thing here is I think a lot of the data sets that are being part of this MLflow are ultimately feeding back into the governance processes that organizations may have. So a lot of these statistics and data sets that are coming out, your confusion matrix, et cetera, can then feed back into the overall governance process of your model management. Yep. Absolutely, Kevin. So as you can see, we have several runs already for the same start date model. This is the training set model. You can see what's accuracy and the number of sample. So here we use this MLflow model to track the model performance and as well as save and manage the actual model binary in the serialized format. For example, for a secondary model, it will save as a Pico format and for a Spark ML model, it will save as a Parquet format. So let me jump back to the Ignite IQ. Okay, so at this point we already created a model using this Ignite IQ element too. Let's move on to the next step, which is we want to start annotate, prepare our data set for the model training. So as mentioned earlier, the whole Ignite IQ tool is designed to manage the complete lab cycle for machine learning starting from the data preparation. So let's see if you have one here. I think we see a lot of struggles around getting the training data and how do you get that trained as a back to your data scientist. And this will allow you sitting on top of the open shift allows you to do to better to get better training data annotating that data. So then ultimately your data scientists and engineers can look at it. So, so good. Yep. Okay. As you can see, we have three Ignite models already loaded in this Ignite IQ. Again, it's back and it's read from MLflow and this model into demo is this a starting model. The first thing is we want to have a set of label data for our model training. And as Kevin mentioned, this is often in the hard right to for the data scientists to get training data if this is a surprise learning model. And for our start data model, we need a bunch of contract data, the raw PDF, and for the SME from business side or data scientists, they can use this Ignite IQ to manually label our target results from each documents. As you can see here, where they have the label for the start date. The actual text is shown here. The reason we can show that actual text is all the documents. The scan PDF is already OCR. So we do have the OCR text without the backhand. So let's say if I draw another bonding box in the different area, you will see that it will return in the text data from OCR. In this way, the SME or data scientists quickly label the documents by just drawing a bonding box around the information they need. And move on to the next document. Maybe just to add a little business context here is what we traditionally see is business users might want to get certain information out of unstructured data set. So for instance, if it's a contract, they might want to pull out the contracting terms or they may want to pull out the effective date or the completion date of the contract. And be able to make business decisions on that. Are they getting the right services for the contract? Is it something that maybe is dealing with live or where you have to figure out what the new rate is to be changed? So traditionally business people, business will ask a lot of questions to documents. Those questions have answers that are in the documents. And the annotation process allows us to annotate those answers, specify them where they are inside the particular delume or the upload from the OCR process. And then allow the data scientists to figure out if they want to use some type of machine learning model to be able to extrapolate out the information or some other technique. To consistently find that right information. So decisions could be made from the business side. That's one of the areas of it. You can also do straight classifiers. If you have a bunch of documents, you want to classify them to different categories. You can label them that way as well. And then the data scientists can see the information to start building their models. Yes, Kevin. Once you finish a manual label for the training data set, we can execute as a model and generate accuracy for the training data. Because normally the data sent here may run like multiple experiments, multiple runs. You can also track the accuracy distribution and the accuracy trend from this history chart. Again, all the metadata performance metric will be stored in the MLflow and in the real-time track here. Moving on to the test, similar to the training data set, we also want to prepare the label data for the test set. Again, data scientists or SME can log into each documents and manually draw the bounding box for the actual label. Once this is complete, they can generate a test data set accuracy for the training model. Once the model is fully tested, we can move on to the last step, which is hold off data set. You can use this data set for validation of your model. Each data set is a new document that the model has never seen before. It creates a new hold off set. This is where we envision having a business SME coming into the start doing the validation of your data sets, of your hold off. How accurate was the actual model itself? Once the SME is prepared as a hold off data set, they can use the test for training model for processing each document. The model will generate the default predictive result with accuracy. At this point, we do see some output by the model looks correct to us, but the result is off. We'll start the menu intervention step to go through each model result and either accept the result or correct it. For example, for this document, the result looks good to me, so I can accept the result. This result is also good to me. Moving on to the next one, since this detection is off, we can reject it and manually correct the right start date. For example, let me pick up this one. That's our effective start date. Let's save this result here. What happened is we just corrected this document result generated by our training model. For this correct information, and for the next training or next model updates, it will automatically use this correct information label to retrain our model to correct the result. Maybe something to mention there, when we initially talked through this, we said that all of our data is stored in a loom. This is the same concept for when you're using these inputs for the business, the annotation UI. When a data scientist gets the output of the corrections that the business is making or the interact or sees that they had in their prediction, they get to see that information into the loom to then retrain their models or update their rules or whatever they're doing to try to extrapolate out that information. So again, one of the things we had data literacy is how do you kind of have the understanding of data through a life cycle is processed. And one of the concepts here, we have our core concepts in our loom, the stored track managing kind of the data through the life cycle of the program or the project, I should say. Yep. Okay. At this stage, we are pretty much done. It was a whole machine learning life cycle, and we can go back to our unit admin tools to update our model status to complete or if the model still needs more holdout testing, we can equip it as a validation step. Yep. And all the whole tools is deployed on top of a unite platform. Yeah. I think you bring up the PowerPoint one quick time before you go back into open shift. I just want to show where you were in that life cycle right there. Yep. If you think about, if you think about what we are doing, there was the activity of the OCR and which was done already that OCR and then feeds into those business input function. So where you can start doing the annotations and where you can start kind of marking up your documents. That then goes back into the data scientists and then once they do and they build and they train the model, there might be a smart sectioning model. For instance, they might want to break the document down in the section so they can more granularly, you know, make predictions on the data sets that are being highlighted. They could add some spacey there to enhance the data to better find the information. But these steps along the path of after you OCR it after the business comes in and gets the annotations and the markups. You know, the next part then is to start breaking that problem down to be able to get the information out that ultimately you want to use to make your business decision. So again, we've kind of run one part of it here to OCR it so you can see the document on the screen like you did. The business will do the annotation you start creating different models, whether it's a model for smart section or you want to reuse this. You enhance your intelligent domain name engine. You add space to get better Richmond across of it. And then finally what on Fay will now show is these components will execute in a workflow that can scale up or down. So if you have to OCR we know OCR is a heavier process maybe it's OCR a thousand documents. You can have a thousand components that are running each time the components complete. It's going back into Kafka to the Kafka know and then your next component in the workflow is picking this up. So we'll do a small demonstration of the annotations been done. The models have been built and now you sort of want to execute this pipeline through these different steps to produce an output. And that's what I'm face going to show you now. Yep. Okay, let me jump back to where we are for the net platform. Okay, so just quickly I'll show you different components we deployed. We have A4 site deployed for most of our storage application including the object storage mail in the distribution mode, two-keeper, HA, Kafka, HA, data search, Postgres, and JFound Art Factory. We also have a bunch of deployment type components shown in here including the WebSys Spark, ML lead component, and a load balancer and janks, HBase API for read write from HBase, annotation tools, component builder, et cetera. So after using the CSAD to deploy the complete in-app platform OpenShift, we can let the data scientist or the engineer to use this platform to launch or create an arbitrary Ignite workflow for their machine learning pipeline. So the first thing. And I guess I'll say just one quick thing. You're going to be using a Jupyter Notebook to show the ability to create a workflow, which is each component that you want to execute and then executing it through. Or as we've seen some other clients and we do it internally, you can call a RESTful service that sends in your workflow that also executes this end-to-end pipeline. Yes, yeah. So this is Python SDK. We created, it's called Ignite Connect. But as Kevin mentioned, you can also directly submit your workflow in the JSON format to launch your machine learning pipeline directly through the Ignite API. Yeah, but the demo I'm going to show you is using Ignite Python SDK to create workflow and execute it using Ignite platform. All right, the first thing is we need to import several libraries, Python libraries for Ignite. And then we will define our workflow. Here, the first thing is we will integrate some PDF, scan PDF image right from the local disk. And then it will come to the workflow definition. Here we will have several components we want to execute in this workflow. The first thing is because PDF is a scanned PDF, we need to convert from the PDF to the image. We are using this PDF tool and we call it page scanner components. You need to specify component name, packet name, docker image with the tag information here. And based on the number of documents you need to process, you can horizontal scale, you can set the number of posts you want to execute for this component in OpenShift. And also how many documents you want to run in one batch. As you can see, this is very flexible and highly customized for your own processing. The next component we want to pick up is Tesseract OCR component. We also need to define some parameters that you want to pass through the Tesseract command. And similar to the first component, you need to define the packet name, component name, image, docker image with the tag information, instance, batch size, etc. We do have two more components, SPACI, which is running the ILP processing and intelligent domain engine to extract interest field right from the financial contract documents. Once you define each component using the Python SDK, the next step is you can create the workflow. So it's actually defined the workflow pipeline by defining a data-directed asset graph, that. Similar to Sparkon has, at this point it's still like a lazy evaluation. You just create the edge for the components, what components you want to execute in your pipeline and with which order. And then it won't execute until you create the workflow and, let's say, kick off the workflow. So I'm going to run this. The infrastructure kind of foundational pieces of the platform exists, but none of these other containers are deployed onto the platform until the execution of the workflow. And then there's the determination of how many do I need, so how many OCR jobs do I need to run, how many containers do I run. And then we'll run in parallel, complete their job, and then they'll all shut down. So it's only using the capacity when it needs it, and then it shuts down and produces the output. Yes, Kevin. And once we start the workflow, the job actually, you know, submit to the back end for the back processing. So it's asynchronously. And to check the result, we can go back to our OpenShift and look at the pause here. And then you will see. Okay, so you'll see we just finished the page standard components, the first component. And it's completed, it's terminating right now. And move on to the next second component, which is test write OCR. And it's launching the pop right now. Okay. Also, if you don't want to use the OpenShift portal to check the status, you can also use our STK, which is the workflow status, you can check the status on here. Okay, so basically it returned all the component status in your workflow where they complete the page standard, the first component, and now it's running the OCR. The rest of the component is in pending state. Okay, so OCR is up and running. So we can go to the log and check the status of OCR. So we have two PDF documents processing here. So here is a refresh list to see when OCR complete and move on to the next component. Once all the steps defined in your workflow complete, you have got a final result in the loom format. And you can check what's the extended field result. Back here and OCR is still running. Right. I think at this point that cover of my demo. I'm just waiting for the workflow complete. Great. So again, just a recap on what we saw, we went over a little bit on why we decided to invest in in our overall night platform and I apologies. I did get kicked off a little bit there. We had a storm in the past through, but we saw why we would build Ignite, the kind of capabilities of Ignite. It's an open ecosystem built on containers, microservices that can plug into other offerings. Other cloud offerings, other data science offerings on prem and helps to manage the full and lifecycle deployment and production as well as model management of a model. Concepts built on top of the loom. So loom and loom out. It's easy for everything to communicate with that. And then at the end of it, it produces some type of output that's usually then fed to a downstream application. So there could be like an exception process where any of the predictions that need to go be reviewed go into an exception queue once I could feed through feed through in the business system to help make those business decisions. But that was I think everything that we wanted to show. And again, apologies for the a little often on there with connectivity.