 Welcome back everyone. We are going to head into our next session, which will be featuring a data gumbo and data gumbo will be reviewing the open footprint calculation engines along with options to be made available. Our first presenter will be William Fox, who is currently serves as the chief product officer for data gumbo. And prior to data gumbo, he was director of operations for Acre Solutions Drilling Technology and was also a commissioned officer in the US Army where he held command positions in South Korea and Baghdad. He leads product strategy and design for data gumbo enterprise grade blockchain platform. So thank you William for your service. Our other presenter is Javier Espinosa. He's the VP of engineering at Data Gumbo. Javier is currently serves as VP of engineering for data gumbo as I just mentioned, but he also has 20 years of experience in the software industry leading software development teams in different industry verticals such as telecommunication, energy and banking. And Javier also currently leads the architecture team supporting gumbo net. So I will turn it over to both of you. And thank you for joining us once again. Guys, you're on mute. So there we go. Thank you. Alright. Okay, well, this is William speaking here. We apologize for our video camera being off. We have some kind of bandwidth issue. So data gumbo. We were interested in OFP because we were introduced to the team by the folks that sustainability accounting standards board in our day to day business which in consists of automating contracts between companies, mostly in the oil and gas industry. We noticed that we're collecting a lot of the same data that was actually could be fed into, especially the emissions portion of various disclosures and reports. And so, uh, Johan and, uh, Bergard were kind enough to let us help out a little bit on team three, which was focused on the calculation engines. Prior to us coming on board, the team had already identified that there are multiple different scenarios by which companies may wish to input data, utilize either customer standard calculations, and then output that data in a standardized way so that it could be shared both across companies and with auditors and so on. And what you see on the screen here are the five different scenarios, which are basically a combination of bring your own data, bring your own calculations, bring your own outputs with one end all the way to a more standardized call out to rules and calculation engine that is sort of pre loaded with different standards and different calculations. And so our, our thought was that maybe we could come up with a couple of options using open source software that could be plugged into the data model that exists already for a P to give companies flexibility and handle any of those scenarios with one set of software instead of having to have different groups. So with that, I'll hand over to Javier, who along with Henry, did all the actual work. And he's going to walk you through what they've come up with. Okay. Hi, everyone. So, based on the use cases that just we mentioned. So we started doing the analysis. We first started doing a main assumptions. And here are the two main things. The first thing is that all the data regarding the parameter before conversion factors and formulas will be a story in the data platform service. So the second, the second assumption was that for the for the time being the authentication authorization is not part of the solution. At this moment. So we will try to we try to focus more in a how the calculation engine should work and what would be the main criteria, regarding the design, what is the criteria that we need to follow. So for that we identified main attributes, especially what people some call non functional attributes of the system. So we identified that we are trying to using these attributes as a main criteria to for us to define what is the design and architecture of the calculation engine. So here are the main attributes we consider that is the any module that is part of the calculation engine has to be the couple. Also, the calculation engine should be able, it should be extensible in a way that we should add more functionality as we go and then adaptable in terms that we should be able to receive data and be able to convert data from different formats and structures to interact with different systems. Also, we think that a multi tier multi layer approach is the best approach to follow here in a way that we can define different building blocks different layers, each one with a single responsibility. Okay, so I also as part of this process we went through across all the community and trying to find a different open source libraries that will help us to accelerate and also we don't want to reinvent the wheel there is a lot of functionality there in the, as an open source, and we were trying to focus in three two main things right one is we wanted to find a mathematical calculation engine, right that received mathematical expressions and then a by race the expressions. And we found some recommendations here like a much is is very popular and then there are other ones, most of them are in no GS platform but there are many different language. So in addition to that we went and also look for when we have a calculation engine sometimes, depending of the different, there will be a business rule associated with that. So not necessarily, you want to calculate the mathematical expression, there will be also cases where you receive data, and you need to do the transformation of the data based on conditions. So for that, sometimes we decided to possible to add a layer of a business rule engine in a way that you receive the data and based on conditions three, you can execute a specific calculation of formula. So for that, for example, we, we can, there are different engine rules in the market, open source, one is the rules engines in Java, and then we have the node rules that is in no GS. Again, all these are part of the process that we were to identify different scenarios and identify different open source libraries that will help us to achieve what we want to do to satisfy the use case. Now, when we did analysis for all the mathematical calculations engines or libraries, we try to make sure that we satisfy at least the simple linear operations like addition, subtraction, multiplication, but also more advanced. So the capability to extend and to improve if we need that, if the calculation becomes very complex, then we wanted also we are looking for libraries that can support, let's say, trigonometry, exponential, square root or maybe differential calculus. Right. So, and that's one, one of the criteria we were looking in the in our recommendation for the open source libraries. Now, on top of that, in top of that, we have meetings with the data architects, regarding how, more or less, the data will be stored in the OFP platform. Based on that we identify different parameters, formulas, activities, all these related to the calculation engine. So the calculation engine will run, but all the data will be stored in the OFP data platform. That's the main idea here. Now, here, I'm trying to show after all these analysis and all these kind of exploration, we went to look for different scenarios. So, we, we, we are presenting now kind of the recommendation, the architecture and the design that we see in the execution model of the calculation engine. So we identified multiple layers. The first layer is the trigger is the trigger layer is how we trigger the, the calculation in. So, right now, there are many ways we are recommending it could be we can trigger the calculation in using just restful API, maybe using schedulers timers, right for a batch processing, or maybe we can, we can also trigger on demand. And even driven calculation. So that's the first layer that will help us to the couple the, the first, the entry point of the calculation engine, how you start the calculation engine. The second layer has to do with once you got the input of the data has to do how you read the data that you need, right, how you do the, you do the adapter. In a way that the data has to be transformed, you need to prepare the data and all the dependencies in order to fit the mathematical expression calculator. So we have a formula where in this case, for example, you can see the formula. And then we need we need to put all the parameters in the right place so the calculation, the expression parser will read it and then evaluate and give us the expected results. In that process we want we will interact with the, if you see in the right side, we will interact with the platform. We will read the data that we need and we will write always, we want to make sure that we keep always the lineage of the data, we want to make sure what happened with the data. The data came in this layer, moved to the second layer, moved to the next layer until the end. So that's more or less what we are trying to, our approach is, it's a multi layer. And at the end layer, as you see is the layer that once you do the calculation, we need to write the results to, to the platform to the IP platform, but we should be open to write to any place to so that's why that layer is very important to be responsible. If we want to later if we want to interconnect with other systems, we should be able to do it without affecting the main core functionality of the calculator. So here I'm showing we are what I want to show you two use cases more or less, how this will play out. So we are assuming in this slide we are assuming that the rest, the trigger is the restful API, someone will send us data. Then we will go in step number two, we will read that data, we will do the right valuations. Then in step number three, we will go and fetch the data that is needed. For example, the conversion, the formula, the expressions, the default factors, we will go and read it from the OFP platform. And then based on that we will prepare the data in order to call the actual mathematical calculation range. It will be first the passing of that expression and then the evaluation. Once we complete the evaluation, then that will get fit in the output and writer, the output writer and adapter layer. So here, one thing that we are saying is local that all these layers run in the same node, in the same VM, all this is local. So there is no need to go externally. The core of the calculation is running in the same program. In the other use case, so we are trying to, the green area is, we are assuming that the green area is not in the same place where the calculation is running. So we are assuming that the green area is in another place. It's remote, it's in a remote server. So what we are doing here is so that again, we call the restful API, we do the proper validation, we gather the data. But now when we are going to execute and calculate the actual calculation, we will call a remote a restful API or remote procedure in a way that we can calculate that and then get the results. And then the result will go through the next layer to the writer layer and the adapter layer and then with that we will collect the results. So as what we are trying to show here is by doing this kind of approach, multi-layer or multi-tier approach, we are able to define different building blocks, define specific responsibilities, right? And based on that, we were able to adapt and satisfy all the main use cases. So here are some examples, how to use the rule changing. Here for example, it's an example of condition, right? So if we want to know, for example, if you were born in this day or before or after, then you will get the fee will be different. So you will get a different fee or different tax. All this can be modeling rules changing the same thing. Here is another, another example, how to use the rule engine in the calculation process. In this case, it's a decision tree, you get the data, but there are conditions in this case, for example, if the transaction amount is greater than this, then you do this, if it's not, you check again, you check, you check another condition and then based on that condition, you will decide what to do. So that flexibility, a rule changing will provide to the calculation in overall. So also, in addition to all this, we try to identify, what are the, well, at least what we know in terms of what are the formulas and the calculations that we will deal with, at least initially. So initially, as you see here is an example of we are trying to calculate the CO2 emissions, right, for stationary combustion calculation. And as you see is the formula in this case is very simple is you will provide either the weight or the consumption, right, and then you will multiply by the conversion factor. So we need to identify the conversion factor, but the conversion factor depends on another variable. So that's one use case that when we go to the live demo, I will address, right, we will see how all this is tied together. But this is an example, a classic example that you will see across multiple calculations is you get received data, and then you receive the input data and then you need to find the corresponding conversion factors and apply the formula. Another example that we were looking trying to find what is the complexity of the formula is, for example, when we talk about the air emissions, right, the airplanes or flight emissions. And we found, for example, in this case, the formula includes exponential. So if you have a you do the summation and you see is a factor A plus plus B times C to the number of miles minus one. So it's a little more complicated. And we wanted to make sure that whatever solution that we have, right. It's able to resolve this kind of equation. Okay. So, so now I'm going to switch to the live presentation. I'm going to cover something at least to show all this, what we already discussed we are, we created some kind of a POC in order to show at least the conceptually how we think this will look and also the challenges regarding that. So here we prepare a small prototype. This is not for any. This is not the actual UI, but this is for us to provide an idea how we think this will look at the calculator, the calculator and the calculation and you should look. So we are, we are thinking that here, for example, you will see, right, the, a different set of calculators calculators, we mind that the community will come right and create different calculators. There will be a standard calculators, right, that people will subject matter experts they know they should be able to create different calculators but also people who who wants to experience right so they can create their own custom calculators. Okay, so this is more or less how we think we model in order to try to model the kind of multilayered approach. So, here is the way how we model right so the calculator. Normally we have a mathematical expression in this case for a stationary combustion, right. So we have two mathematical expressions. This calculator will return to results. One is the CO2 emissions and the end to emissions. Now, if you see this, this emission will have this formula, it will multiply the weight times the heat content times the CO2 factor that is a conversion fact. And here is the unit that will the calculation return. So the same thing for the end to end to all emissions. So but in this case we will use a different is the same will enter the weight, the heat content and a different factor here. So, and the unit that this calculator will return. So here we are specifying what is the main mathematical expression and what are that we want this calculator to to execute. The second day it is the variables or the mapping the parameters what are the parameters that this calculator. We need right so in this case, all the parameters are for example the weight right so the way the weight each variable which parameter could be right now from these three different types. It could be input input means that it's coming from the pale from the restful API. A lookup means that we need to do a conversion before we calculate we need to go and look up maybe a conversion factors look up table. And then the rules rules means that we need to execute a rule that maybe there is a condition if this is the value comes with this is greater than this then execute that. So right now for the purpose of this demo we implemented just the input and look up. So in this case we said the weight is a variable that will be input by the user, the user needs to enter that. And then the unit will be tons, short tons. And then the other variable is the heat content for heat content or CO2 factors into all factors, we are assuming that this will come from a lookup operation. So we will go to a conversion factor conversion factors table, and we will look that value based on these keys, the category fuel type, category fuel type, and then we will return based on in these units, the values. And so based on that also we since we need category and fuel type category and fuel type will be variables to where we what we are expecting the user to enter to provide those values. Now here below here we have at least this is a simple example of conversion factors for a stationary combustion. So here you are able to upload to put the conversion factors and the mapping. So what the calculation and you will do is based on this definition, whatever category fuel type the user provides in the UI. It will map in the it will do a simple lookup and then find the corresponding conversion factor. As you know, we are following the headers in order to match we are following the headers to match the values of the, for example, in this case, heat content, right. So, the, the name of the variable match with the heat content of the conversion factor team. So once once we do that and we set up this calculator. And we think that it's okay we have the option to test. So we can click here and test and see all the input variables that we define in the calculator will be, you will be able to enter and select that. So, in this case, for example, we said we decided the category fuel type will be a user input data input variables so that means the user needs to provide that. The same thing with weight. So here in the category. We have only one option right now we select the stationary combustion and then we select the different types of fuel. Right. So, and then I enter the weight based on the in this unit. And I click calculation and then I got the CO2 emissions and the emissions. And how do you, to your point earlier in the slides, because this is all supported by rest. Yes, you don't have to do this manually for everything. Right. You're showing what the is going on, but the intent would be for large companies would be just feeding into this and by getting results. Exactly. Yes, this is this is the environment where you play around is to play ground, you define your calculators, and then you publish the calculator so anyone can call from different place right so but the idea is that we believe that having this playground space or for the community right will allow us to first to foster the sharing the knowledge right so people with knowledge with expertise can create their own calculators put it as a standard people will go there learn and not only that. Learn the best practices but also accommodate based on the circumstances right because this kind of scenario depends on regulation in different in different countries in different places. So, but by doing this, you have a place where you can go test, do experiments, and then once you feel it's okay, we are we envision that you should be able to publish to the world. Everyone should be able to see my calculator and using using just the red full API as you see all this is dynamic and computer. Right, so it shouldn't be. We don't want this to be super tight. It has to be configurable. The user should be. You should come here. Of course, based on the right documentation try to do the right calculation. Okay. Yeah, so that would be my. All right, so that's the end of the demo. Do you want to stop? Does anybody has any questions? I think we have a few minutes left in our time slot. So, here is more, more or less the, in general, the, it's kind of the planning, right? So, regarding how we want to approach this and the resources, because we are getting kind of baseline. Right. What is what we would like to do this demo the prototype is to give that kind of approach so people visualize and see what where we are what is the direction and then, but in order to have a full production ready or we need to allocate resources. Right. And also, they find the technology and I continue working on this. So, for that, we, we estimate this is a estimating general. What we would like to do, right? More or less that a time frame, how long it will take. And how beer. So, you got a question from Billy at what data is used to test the calculations. Do you imagine a community governance process to standardize or certify calculators. So, I think that's to be determined. Yes, so that's, you know, if, if, you know, E Y comes on here and says, I'm going to certify 15 of these calculators. That's probably better than if. William Fox said, is I'm going to fix these calculators and there's definitely ways we can add metadata and fields and a workflow for that over time. And in terms of data, I mean, we're just using, you know, David down to Excel, but presumably companies will be able to pull, you know, expenditure data from the recipe or as inputs for this and see what their own data looks like in the system. Yes. Yes. So. One other point also, guys, the resource you're talking about, we are recruiting those resources as we speak. So, I hope that in the next couple of weeks we have those resources together. So we can start doing the work which proposing to do. Absolutely. Great. I was going to say, if I can just add one more point to the question around this, the sort of certifications and in many cases, especially in the world of carbon. I mean, there are governance processes, ISO standards, etc. That are used and or regulatory says that sort of define these and so provided you've got a whole ecosystem of third party auditors and verifiers that will that organizations used to assure the numbers that they that they publicly report no different than they do with financial data is a similar kind of concept. So, I would imagine that that that governance process also starts to align around that that sort of a third party assurance, whether it's certification or reasonable assurance as well. Is this something to consider? Good. Other questions from the group. I'm happy or maybe one point I was thinking about this and late so point that I answered back, but I wanted to get your sense as well or get your feedback. I mean, obviously we're talking about calculations and estimates and so on and so forth. And as organizations. And as technology and it evolves, we're moving into more of a monitoring and measuring culture. I mean, what's your view around potentially some of the complexity of the calculations that are required in light of better technology to measure and monitor emissions directly. Yeah, well, I think what we're, we're seeing today is that, you know, companies are voluntarily or under pressure because they need to raise money and it's time to that putting out better. You know, putting a Honeywell camera out there to get a real time view that are methane off the pipe. That sort of thing. And, you know, they're also requiring more data from their vendors, like the trumpets. For instance, you know, typically you'll see something where mileage and depth, the merge of part of the contact. Well, okay, if you're going to pay off that, we're going to collect it for commercial reasons. And so to your point earlier about more data of all types, I think there'll be a two stage thing where you do sort of commercial calculations that you need to do to pay vendors or or build customers. And then after that data has been validated from a commercial standpoint, a second stage where by API, you feed it into an engine like this and say, okay, we determined that our fleet did, you know. 187,523 miles for customers a and as part of our reporting to them, this is scope three up spinning to them. Run it through the engine and hand it up to them. I think, yeah, there's two stages, maybe moving the three stages using these types of calculations. Yes. And also from the technical side, I see that we we need to move fully cloud computing. So in the sense that we should all this kind of a calculation and it should live in any place and should run in any place should be very available. Especially access to the resource right now is very easy right now we can use commodity servers. There is no need to have a very monolithic application. It could be totally distributed. It could run in different places. And then that kind of I think we are in that stage we can make it all this available for everyone. Right. So to be to use. And I don't think in terms of cost, we are talking about a super like in the past, right? This was, is you try to do this kind of enterprise will take a lot of time and a lot of resources. So that's my point, move it to the cloud computing and then try to use all these virtualizations, new technology, right? Like we can discuss a container base or any other kind of visualization. Right. I was going to say I think any other questions. I think that's the last of the questions. So, so, so thanks William and Javier for that presentation. If I can perhaps turn it back over to you. Thank you, Sammy. And thank you, William and Javier. That was very interesting. I know it's a complicated topic to to describe the calculations and so forth. So really appreciate the effort and wonderful presentation. Thank you.